I noted some open issues on "Classes with Trait Composition"

Mark S. Miller erights at google.com
Thu May 19 06:36:40 PDT 2011


Hi Andreas, yes we have a long history of consider this shape, in fact much
longer than the current shape. The final state of proposals along these
lines is <
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition&rev=1299750065
>.

This approach actually lead to a much more elegant way of providing
encapsulation: by the objects-as-closures pattern, where the methods are own
methods of the instance lexically capturing the constructor's lexical
context. However, we finally gave up on this for two closely related
reasons:

1) Starting from scratch, there's no problem engineering a VM to make
objects-as-closures efficient, especially given the semi-static analysis
that class proposal was designed to enable. However, JS VM implementors are
not starting from scratch. Fitting such a new optimization into existing
heavily optimized engines was thought to be a hard sell. Especially since
all major VM implementors would need to agree.

2) The conventional JS pattern is to place methods on the prototype, not the
instance, and many felt that the main thing classes need to provide is a
syntax to make this traditional semantics easier to express.

Another variation of your suggestion that Tom suggested is that you mix
instance initialization and class/prototype initialization together in the
class body. This obscures both time-of-execution and scope. Methods on the
prototype do cannot have the constructor parameters in scope.


On Thu, May 19, 2011 at 5:36 AM, Andreas Rossberg <rossberg at google.com>wrote:

> My apologies if this has been discussed to death before -- well,
> actually, I'd be surprised if it hasn't (pointers would be welcome).
>
> I think it is worth noting that the baroque notation for defining
> constructors that we see in the C++ / Java / C# world primarily is an
> artefact of the desire to allow multiple constructors with overloading
> in those languages. We don't have that issue in JS, so I wonder why we
> cannot go for something more elegant? There is precedent in other
> OOPLs (off the top of my head, e.g. Scala and OCaml) for putting the
> constructor arguments on the class head directly, and executing the
> class body like a block when the constructor is invoked. AFAICS:
>
> -- This approach is significantly slimmer (and, I'd argue, more
> readable) than the discussed alternatives, without needing any
> keywords:
>
> class Point(x0, y0) {
>  public x = x0
>  public y = y0
> }
>
> -- It naturally allows what Bob was suggesting:
>
> class Point {  // no argument list would be shorthand for (), just
> like when invoking new
>  public x = 0
>  public y = 0
> }
>
> -- It avoids additional hoops with initializing const attributes:
>
> class ImmutablePoint(x0, y0) {
>  const x = x0  // just like elsewhere
>  const y = y0
> }
>
> -- The constructor arguments naturally are in the scope of the entire
> object, so often you do not even need to introduce explicit (private)
> fields to store them:
>
> class Point(x, y) {
>  public function abs() { return Math.sqrt(x*x, y*y) }
> }
>
> /Andreas
>
>
> On 19 May 2011 03:31, Mark S. Miller <erights at google.com> wrote:
> >
> >
> > On Wed, May 18, 2011 at 6:29 PM, Brendan Eich <brendan at mozilla.com>
> wrote:
> >>
> >> On May 18, 2011, at 5:57 PM, Bob Nystrom wrote:
> >>
> >> class Point {
> >>   public x = 0, y = 0;
> >> }
> >> let p = new Point();
> >> p.x; // 0
> >>
> >> This is pretty rare, in my experience. A hard case? If the constructor
> >> does set x and y from parameters, then you have double-initialization.
> If
> >> some properties are non-writable, you can't do this. YAGNI?
> >
> > +1. If you're gonna initialize them somewhere, why not always do so in
> the
> > constructor and avoid special cases?
> >
> >>
> >> /be
> >
> >
> >
> > --
> >     Cheers,
> >     --MarkM
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110519/aedbcdda/attachment.html>


More information about the es-discuss mailing list