On Oct 12, 2011, at 7:40 PM, Mikeal Rogers wrote: > What I meant was, object A uses class style inheritance and class B uses > vanilla prototype inheritance and there isn't an obvious signal that they are > different or which style I should use if I'm going to extend them if I'm a > less than expert programmer. > > This is something we might solve with classes in ES6.
Yes, the goal of classes since the beginning of Harmony was "classes as sugar". No new semantics if we could help it. The original sketch by MarkM used the closure pattern, but we ended up favoring prototypes. So classes as proposed desugar to constructor functions. No interoperation barrier with old code that does it by hand. >>> Having just a syntax, even without any more semantics than people already >>> add today, *could* reduce that confusion. >> >> That was the hope. Seems like too many requirements, including ones we can't >> agree to meet now and yet also can't future-proof against, got piled on top. > > IMO, ditch all the additional semantics. Make it pure cane sugar. It adds > clarity to the language around a pattern that is already popular. If people > are clamoring for all these extra semantics then it'll be obvious what should > go in by ES7. We factored out private already, so the only additional semantics have to do with instance variable initialization. Some want at least future-proofing for a way to make a constant instance variable where reading it before it has been initialized is an error. Leaving that out is of course a good idea, but at least Waldemar still objects that we may be future-hostile by doing even minimal classes. At this point, I'm not sure how to get unstuck. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
