Summary: prototypes as classes

Brendan Eich brendan at mozilla.com
Sat Jul 2 20:27:25 PDT 2011


On Jul 2, 2011, at 4:10 PM, Angus Croll wrote:

> I'd argue its a difference in meaning - the proof is that if you removed 'extends' and 'super', the class sugar would support unchained prototypes only. In fact maybe I could live with 'class' alone (though it might give noobs the wrong idea about JavaScript vs Java) - but it's 'extends' and 'super' which add legitimacy to the classical OOP approach.

Indeed Waldemar has proposed (starting at the July 2008 "Harmony" TC39 meeting in Oslo) that we cut back to zero-inheritance classes.

OTOH Mark has worked on a traits-based mixin extension to class syntax based on the work he and Tom Van Cutsem have done (http://traitsjs.org/).

Classes don't just mean one thing. The "lint brush" effect whereby the syntax picks up sevearl styles of inheritance is a real cost to consider.


> >>Some empirical results: "...Studies of C++ programs mention a maximum DIT of 8 and a median of 1, whereas Smalltalk has a median of 3, and maximum of 10. Figure 6 shows that in all but four sites, the median prototype chain length is 1
> 
> Sure, proto chaining was always supported but my guess is that officially sanctioning 'extends' and 'super' will raise the median prototype chain length through the roof - and I can't see how that's good for the language

This is an odd point of view. You think convenient syntax for something possible already will make more silly, tyrannical, ultimately costly single-inheritance hierarchies -- and the lack of such syntax will help steer people toward mixin libraries (all the major JS libraries have some such system, IIRC)?

Why would people overuse classes and single-inheritance? If the convenience of the syntax is an attractive nuisance, should we make convenient declarative syntax for mixins? That was hung off the class proposal but separated out and deferred to help get the basics into ES.next.

It's hard to quantify risks here.


> >>Mixins require copying properties, and there's nothing lightweight (in usable syntax or runtime cost) in that.
> 
> As an aside I'm not wild about the mixin by copying strategy and have advocated mixin by delegation as an alternative.
> http://javascriptweblog.wordpress.com/2011/05/31/a-fresh-look-at-javascript-mixins/ 

That's still copying, but into the prototype for best sharing (and the power-constructor pattern helps share once-per-mixin-per-method closures).

What if there are conflicts? http://traitsjs.org/ takes a "high integrity" approach, throwing on conflict and freezing aggressively. There are many choices. Just letting things silently conflict with last mixin winning seems like a footgun. A composition-time check that throws, but without freezing for all time after, seems like a good compromise.


> >>I think you are protesting too much.
> 
> Yeah you might be right. I hope so. And I'm probably biased because Java taught me to abhor impl. inheritance

I learned the hard way via C++ :-P.


>  On the other hand I held back from writing to this list for the longest time until I was certain I had a serious concern. You made a great language, I'd be sad to see it misused because folks were drawn to the wrong kind of sugar - I know there are a bunch of others who don't write to this list but share my concern. 

Thanks for articulating it. We need to work on quantifying (however coarsely) the trade-offs with no classes vs. prototypal-only classes vs zero-inheritance vs traits.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110702/92649a82/attachment.html>


More information about the es-discuss mailing list