I noted some open issues on "Classes with Trait Composition"
Brendan Eich
brendan at mozilla.com
Sun May 15 23:49:03 PDT 2011
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>
More information about the es-discuss
mailing list