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

Andreas Rossberg rossberg at google.com
Fri May 20 04:34:06 PDT 2011


On 19 May 2011 15:36, Mark S. Miller <erights at google.com> wrote:
> 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>.

I'll have a closer look, thanks for the pointer!

> 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.

Like Luke I was wondering why a change of syntax should affect the
semantics. But after seeing your reply pointing out the problem with
`this', I see your point. Although it doesn't seem to specific to
constructor parameters, but would apply to instance fields in general
with the class-as-block approach. Still sad.

I agree that the ideal solution would be objects-as-closures.
Personally, though, I could also live with requiring instance
variables and constructor arguments always be accessed through `this',
even in that syntactic approach. True, it somewhat obscures scoping --
but arguably, "public" or "private" declarations are not ordinary
declarations, so it's not too hard to argue that they do not actually
bind anything in the "current" scope. Same goes for constructor
arguments vs ordinary function arguments.

Thanks,
/Andreas


More information about the es-discuss mailing list