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

Brendan Eich brendan at mozilla.com
Mon May 16 08:02:58 PDT 2011

On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:

> On 16.05.2011 10:49, Brendan Eich wrote:
>> On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
>>> This looks pretty good at a glance, but it's a lot, and it's new.
>> Looking closer, I have to say something non-nit-picky that looks bad and smells like committee:
>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#inheritance
>> Two kinds of inheritance, depending on the dynamic type of the result of evaluating the //MemberExpression// on the right of ''extends''? That will be confusing.
>> Is the traits-composition way really needed in this proposal? If so, then please consider not abuse ''extends'' to mean ''compose'' depending on dynamic type of result of expression to its right.
> Some simple examples of all use-cases would are needed I think.
> Regarding `new` keyword for the constructor (aka initializer), after all, it als may be OK. E.g. Ruby uses `new` as exactly the method of a class -- Array.new, Object.new, etc. Though,  `constructor` is     also good yeah.

My point is not to bikeshed, rather (a) to name existing prototype properties minimally, (b) to avoid preempting other names.

Good, bad, or in between, the prototypal pattern in JS for constructor C binds C.prototype.constructorr to C. It does not bind C.prototype.new.

> Regarding two inheritance types, I think better to make nevertheless one inheritance type -- linear (by prototype chain). And to make additionally small reusable code units -- mixins or traits -- no matter. Thus, of course if they will also be delegation-based and not just copy-own-properties, then we automatically get a sort of multiple inheritance.

Self has multiple prototypes and you can use them for all kinds of inheritance patterns.

Parents are Shared Parts...

Organizing programs without classes

> Delegation-based mixins though can be implemented as a library using proxies (example: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/mixin.js, implementation: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/mixin.js, notice I also used Object.new :)).

Proxies are too costly, though. They always have a handler full of traps. The idea with classes is to capture prototypal inheritance as used today. The idea with traits is to make composition flexible, with fast failure on conflict and tools to rename around conflicts.

Putting classes and traitts together should be doable but it shouldn't use the same sytnax (extends) and it shouldn't require proxies.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110516/e01954c8/attachment.html>

More information about the es-discuss mailing list