3 ms·

The benefits of prototype inheritance have always seemed rather dubious to me. The programmer wants to express that there are a bunch of objects with the same s

The benefits of prototype inheritance have always seemed rather dubious to me. The programmer wants to express that there are a bunch of objects with the same structure and behavior; the compiler needs to know which objects have the same structure and behavior. Forcing both sides to pretend that each object is a unique and special snowflake when that is both counterfactual and inconvenient for all involved seems pretty silly. That said, C++/Java-style class-based o.o. is no panacea either and having both things in a single language is just crazy.

j13z 12y ago
> That said, C++/Java-style class-based o.o. is no panacea either and having both things in a single language is just crazy. Actually, there is just prototypal inheritance. The whole `new` operator thing (as well as ECMAScript 6 classes) is just syntactic sugar over prototypal inheritance. But yeah, it's crazy that this had to be put in just to attract users (in the 90s, to make it look more like Java; along with method names etc).
ericelliott 12y ago
> Forcing both sides to pretend that each object is a unique and special snowflake when that is both counterfactual and inconvenient for all involved seems pretty silly. That's not at all what prototypal OO does. A prototype in JS is very simple: It's an object, just like any other object. It's not pretending to be anything else but an object. When another object links to that prototype (using the `new` mechanism or `Object.create()`) that object is not pretending to be a unique and special snowflake. In fact, exactly the opposite is happening: It's delegating everything that is "the same" to the prototype it references. The primary advantage to that is a simple matter of memory conservation. Otherwise, you might as well just copy properties from the prototype to the new object. Some functional languages do essentially that every time you create a transformation, because state in some functional languages is immutable. Under the hood, such languages are actually just copying references to shared data, which acts very much like prototypes, practically speaking. The difference being that the language users are not exposed to the mechanism. These are very different paradigms from classical inheritance where everything you extend creates an "is-a" relationship and a single parent object hierarchy. It's a strict tree system. Prototypes in JavaScript do nothing of the sort, because you can use dynamic object extension to build up a prototype from as many sources as you like. The practical upshot is a lot more freedom, no more need for hierarchies, which eliminates the need for "super" calls, which reduces coupling -- the children have no knowledge of the prototypes that have been composed together to create the API of the child. See "Prototypal Inheritance with Stamps" for more detail: http://ericleads.com/2014/02/prototypal-inheritance-with-stamps/ http://ericleads.com/2014/02/prototypal-inheritance-with-sta...

j13z 12y ago

> That said, C++/Java-style class-based o.o. is no panacea either and having both things in a single language is just crazy. Actually, there is just prototypal inheritance. The whole `new` operator thing (as well as ECMAScript 6 classes) is just syntactic sugar over prototypal inheritance. But yeah, it's crazy that this had to be put in just to attract users (in the 90s, to make it look more like Java; along with method names etc).

ericelliott 12y ago

> Forcing both sides to pretend that each object is a unique and special snowflake when that is both counterfactual and inconvenient for all involved seems pretty silly. That's not at all what prototypal OO does. A prototype in JS is very simple: It's an object, just like any other object. It's not pretending to be anything else but an object. When another object links to that prototype (using the `new` mechanism or `Object.create()`) that object is not pretending to be a unique and special snowflake. In fact, exactly the opposite is happening: It's delegating everything that is "the same" to the prototype it references. The primary advantage to that is a simple matter of memory conservation. Otherwise, you might as well just copy properties from the prototype to the new object. Some functional languages do essentially that every time you create a transformation, because state in some functional languages is immutable. Under the hood, such languages are actually just copying references to shared data, which acts very much like prototypes, practically speaking. The difference being that the language users are not exposed to the mechanism. These are very different paradigms from classical inheritance where everything you extend creates an "is-a" relationship and a single parent object hierarchy. It's a strict tree system. Prototypes in JavaScript do nothing of the sort, because you can use dynamic object extension to build up a prototype from as many sources as you like. The practical upshot is a lot more freedom, no more need for hierarchies, which eliminates the need for "super" calls, which reduces coupling -- the children have no knowledge of the prototypes that have been composed together to create the API of the child. See "Prototypal Inheritance with Stamps" for more detail: http://ericleads.com/2014/02/prototypal-inheritance-with-stamps/ http://ericleads.com/2014/02/prototypal-inheritance-with-sta...