What do we still need from a class-like abstraction (was: `this`: methods versus functions)

Jake Verbaten raynos2 at gmail.com
Thu Nov 10 09:35:07 PST 2011


The only value prototype inheritance gives is the fact you can change the
prototype and changes are reflected.

If you do not want that feature then use mixins.

On Thu, Nov 10, 2011 at 4:56 PM, Andreas Rossberg <rossberg at google.com>wrote:

> I wholeheartedly agree that mixin composition is superior to both
> prototype and class-based inheritance. I'm not sure I entirely follow
> your point regarding `this', though.  (TBH, I'd prefer not having a
> `this' keyword at all, because not being alpha-convertible, it doesn't
> really compose with nested definitions, and invites subtle mistakes --
> a lightweight syntax for binding an arbitrary identifier to self seems
> better.)
>
> The traits proposal currently is nice indeed, but also quite heavy on
> going through reflective meta levels. It will require significant work
> to make that efficient.  But I believe there is potential for VMs
> optimizing e.g. nested closure creation for certain patterns.  Though
> obviously, implementers currently have other priorities (like catching
> up with ES6 features first :) ).
>
> /Andreas
>
>
> On 10 November 2011 16:59, Mark S. Miller <erights at google.com> wrote:
> > Note that the traitsjs library provides:
> > 1) all the safety of the objects-as-closure pattern you show below (and
> more
> > because it takes care of the needed freezing).
> > 2) still allows intuitive use of "this" to refer to the instance itself,
> > bound not lexically, but rather at object instantiation time. This
> enables
> > 3) a superset of conventional oo inheritance and override patterns, where
> > the lookup of "this.getX()" is determined by the concrete "subclass",
> rather
> > than either the lexical occurrence of "this" or "self" (as below) nor by
> the
> > client (as in JS prototypal inheritance). I say "superset" because it
> also
> > provides
> > 4) an understandable alternative to multiple inheritance: symmetric
> traits
> > composition with explicit conflict resolution.
> > TraitsJS also has the same problems that presently deter people from
> using
> > objects-as-closures:
> > 5) Without VM support, it costs at least an allocation per method per
> > instance, making it much too expensive. (See micro benchmarks in
> > <
> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/37485.pdf
> >.)
> > 6) It is observably different than simply being sugar for JS's prototypal
> > inheritance, introducing a non-uniformity when linked with libraries
> > using prototypal inheritance.
> > I think I am satisfied at this point that "prototypes as classes" has
> made a
> > plausible enough start on addressing point #6 in its own way, without
> > introducing an explicitly class-like abstraction, that we may not need
> > classes-as-sugar for prototypal inheritance. This leaves #5 as *the*
> > pressing problem for use of either safe pattern: objects-as-closures (as
> > below) or traits (as in traitsjs or possibly eventually class-like sugar
> for
> > them as previously proposed).
> > My previous proposal for class-like sugar for traits composition was not
> > popular. Whereas, in the absence of problem #5, I suspect the traitsjs
> > library would be. As previously observed on this list, traitsjs is more
> > JavaScripty. Ideal would be for JSVMs to magically make traitsjs
> efficient
> > without requiring any language changes. If this is infeasible, perhaps we
> > should instead be looking for the minimal language change that would
> enable
> > a revision of traitsjs to run efficiently on ES-nest-next JSVMs.
> > I say ES-next-next because it is too late to consider any such language
> > change for ES-next. However, implementation experiments need not wait.
> >
> > On Thu, Nov 10, 2011 at 7:19 AM, Andreas Rossberg <rossberg at google.com>
> > wrote:
> > [...]
> >>
> >> No, that's how it works right now. The alternative is to lexically
> >> close all methods over self at construction time:
> >>
> >>  function Point(x, y) {
> >>    var self = this
> >>    self.x = x
> >>    self.y = y
> >>    self.move = function(dx, dy) { self.x += dx; self.dy += dy }
> >>  }
> >>
> >>  function ColorPoint(x, y, color) {
> >>    var self = this
> >>    Point.call(self, x, y)
> >>    self.color = color
> >>    self.recolor = function(c) { self.color = c }
> >>  }
> >>
> >> As said, this doesn't play well with prototype inheritance. You have
> >> to put all methods that refer to self on the object itself. But "inner
> >> constructors" are straighforward and safe.
> >
> > --
> >     Cheers,
> >     --MarkM
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111110/580eec77/attachment.html>


More information about the es-discuss mailing list