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

Bob Nystrom rnystrom at google.com
Tue Jun 7 12:57:31 PDT 2011


It was. The main problem that comes to mind is that it doesn't work with
anonymous classes. Even with named classes, I find it can be tedious and
repetitive, especially with long class names.

Javascript's current class-as-constructor syntax is nicely terse and doesn't
require stuttering the "class" name. I think the goal with the class
proposal was to aim for that level of syntactic lightness.

- bob

On Tue, Jun 7, 2011 at 12:42 PM, Gavin Barraclough <barraclough at apple.com>wrote:

> Brendan,
>
> Out of interest was a C++/Java style constructor considered, with the
> constructor name matching the class name?
>
> cheers,
> Gavin.
>
>
> On May 16, 2011, at 8:02 AM, Brendan Eich wrote:
>
> 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...<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.1447&rep=rep1&type=pdf>
>
>
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.1447&rep=rep1&type=pdf>Organizing
> programs without classes<http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=77703261C2A470793139A1F79D8467AC?doi=10.1.1.127.5320&rep=rep1&type=pdf>
>
>
> <http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=77703261C2A470793139A1F79D8467AC?doi=10.1.1.127.5320&rep=rep1&type=pdf>
>
> 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.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> 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/20110607/134c89cf/attachment-0001.html>


More information about the es-discuss mailing list