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

Reply via email to