I noted some open issues on "Classes with Trait Composition"
brendan at mozilla.com
Sun May 15 23:49:03 PDT 2011
On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
> 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:
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.
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss