The interesting thing here is: why do big companies don't need to keep their talents? Does bureaucracy compensate for lack of talent? And vice versa? Does this also mean that you can innovate without talent?
big companies exist to execute a well known business model. they invest in lobbyists to keep the business climate stable so they continue to execute their business model. it usually makes more sense to outsource innovation -- e.g., invest in and acquire startups.
I've been getting along fine with nothing but util.inherits from NodeJS.
Are there any real advantages to the "set the prototype to this object" approach versus building it up by assigment?
function Animal(legs) {
this.legs = legs;
}
Animal.prototype.speed = function() {
return legs * 10;
}
util.inherits(Dog, Animal);
function Dog(name) {
this.constructor.super_.call(this, 4);
this.name = name;
}
Dog.prototype.speed = function() {
// I don't disagree that more sugar here would be good
return this.constructor.super_.prototype.speed.call(this) * 2;
}
Beyond the need for calling the constructor (which I'm currently viewing it as an unnecessary hidrance [objects are already initialized]), Object.getPrototypeOf may provide a way out - but maybe not the way you intended. Have you considered it?
Works, but is even more verbose. However if you use Object.getPrototypeOf on this you fail the recursive problem in nest super calls. Read the stackoverflow euestion
I was deliberately excluding the constructor situation. I should have made that clearer in my previous comment. I think the way out of the constructor mess is not to require them at all.
I do think the Object.getPrototypeOf approach is feasible for methods.
Well actually unbounded recursion and infinite memory is what is required for turing equivalence. Conditioning can be present in a non turing complete language. I added the practically because all computers on which language models are built on are finite. It is easier to get turing completeness than to ensure you haven't accidently allowed it to sneak in - as evinced in C++ templates.
I don't see how Object.create goes against the grain of the lang. On the contrary, `new' was bolt on to make js look like classical oo languages. I have found, in toy and exploratory projects at least, that using variations on Object.create [1] is a nice, strong pattern, that really gets the best out of js. It certainly feels more natural than class based oo. Though, take it with a grain of salt, since I'm unable for now to provide an example backing my thesis :)
I would love to see an example backing your thesis, if you don't mind digging one up.
I've had this debate with folks many times before, and literally every time it comes up, they're unable to find an example of using prototypal inheritance in a style that wouldn't also be considered classical.
If you think that writing:
var point = Object.create(Point);
... is somehow magically prototypal, while writing:
var point = new Point;
... is unnaturally classical, I'll argue that you're missing the, ahem, point.
They're two different ways of writing the exact same pattern. And, if we're being honest with ourselves, the "Point" object in that code should rightly be called a "class": it's the abstract object that defines the shape of all points. Of course, in JavaScript, we also tend to call it the "constructor function" (which it is, technically), and sometimes, the "prototype" (because it serves in that role).
Very few examples of prototypal inheritance shows it beeing practically different from class based inheritance. If all (non-function) instance fields are assigned new values - like the Point example in the article - it is basically the same.
Prototypal inheritance makes a difference if one instance inherits field values (other than functions) from another instance. But this does not seem to be very common.
I believe one of the original use cases for prototypal inheritance were to save memory by letting GUI controls share common properties. Eg. if you had 10 buttons on the screen which all had the same color, same dimensions etc. With class based inheritance each instance would have their own copy of all properties, even if they have the same values in each instance.
I don't think that kind of optimization is relevant in modern JavaScript.
Well, I have to argue that it's not the same pattern. I think the problem
is that you still like to believe that js has classes, which it doesn't: js
has got objects only. That it also has constructor is an (admitted?)
historical mistake. Just think of all the weird crap that goes on to make
`new func()' work and produce a new object.
What is no mistake is the refreshing change of view you get when you
start embracing objects and prototypal inheritance. See for example the
traits library[1, 2].
[3]: Is a cursory introduction to Self, with another points example :)
[4] Contains an example of my own (heavily inspired by Self and Io). I have stitched together various internet
sources to come up with `clone', an operator assisting in differential
inheritance.
Traits aren't incompatible with classes at all. In fact, Tom van Cutsem, the author of traits.js worked on the class proposal that's going into Harmony.
Aside from the simplicity argument, I didn't see anything in Markus's presentation that showed an advantage of prototypes. His point example is cloning a point and then immediately replacing all of the state, so there's nothing there that classes couldn't do (in less code).
Your gist (especially the color point) is an example of using prototypes in a way that's hard with classes. Fortunately, adding classes to JS won't hurt that at all. You could just as easily do:
class Point {
constructor(x, y) {
public x = x;
public y = y;
}
add(other) {
return new Point(this.x + other.x, this.y + other.y);
}
}
let p1 = new Point(0, 0);
let p2 = p1.clone({
color: '#green',
toString: function() {
return this.color + ': ' + uber(this).toString();
},
})
In other words, adding classes to JS won't take away anything already there. It just gets a really common pattern and makes it much less verbose. The idea is to pave the common path of class-like inheritance, but not to build a fence around it to keep you in.
Object.create(...) is a factory pattern. "Object" is suddenly a factory for making anything, you just supply the blueprint in the form of "Point." So to know what will happen, I need to look at Object and at Point. One strength of this pattern is when I want to handle cross-cutting concerns in the factory. For example, I can modify all objects created with aspects if I use a factory to create them. Or I could have the factory decide whether it is creating Plain Old Javascript Objects or whether each object is backed by persistent storage a'la ActiveRecord.
A factory is very different from a keyword baked into the language. The new keyword suggests that the underlying language is doing the construction, and all of the details about the object being created are encoded in its blueprint, "Point."
I consider a factory and a keyword to be two very different patterns regardless of whether you want to call them class-based or prototype-based.
