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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
