Agreed with Tab, in terms of composing inherited functionality it's hard to beat prototypal and the ease of `Class.prototype.__noSuchProperty__ = function(){ ... };` traitish approach.
I also think Proxy already gives us a way to work around the `__noSuchProperty__` "issue" On Wed, Sep 24, 2014 at 11:17 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Wed, Sep 24, 2014 at 2:56 PM, Brendan Eich <bren...@mozilla.org> wrote: > > Brendan Eich wrote: > >> > >> Tab Atkins Jr. wrote: > >>> > >>> This works great as a general principle, but honestly tons of > >>> languages have already forged this path. It's pretty straightforward, > >>> I think. > >> > >> > >> I made the case for building it in sooner, but TC39 wanted "less sooner" > >> based on library usage. There was a minority position (as voiced; could > be > >> majority) that argued JS is different, object detection plus optional > >> "fields" means this is the wrong direction. > > > > Not trying to be controversial ;-). Would you use ES6 classes and have > the > > ones you wrote all extend NoSuchPropertyClass? > > Using subclassing to bung in some arbitrary trait is really terrible. > :/ It requires either adding it up high in your class hierarchy, or > having to write a custom NoSuchPropertyClass which extends your > superclass, so you can then extend it. > > I'm rather surprised that the group actually considered that sort of > code to be appropriate - it's known that it doesn't compose well with > other traits-as-superclasses or normal subclassing. > > ~TJ > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss