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

[Brendan Eich]

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.

/be


> 
> I have to say this reminds me of ES4 classes. That's neither bad nor good, but it's not just superficial, as far as I can tell (and I was reading specs then and now).
> 
> On the other hand, I'm in no rush to standardize something this complex and yet newly strawman-spec'ed and yet unimplemented. So we may as well take our time, learn from history, and go around the karmic wheel again for another few years...
> 
> I'm not against classes as a near-term objective, but in order to be near-term and not to unwind in committee, I believe they have to be dead simple and prototypal, with very few knobs, bells and whistles. Factoring out privacy and leaving constructor in charge of per-instance property setting, as it is in ES5, would IMHO help.
> 
> /be
> _______________________________________________
> 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/20110515/06fd3df8/attachment.html>