While the class literal proposed by Jeremy is indeed nice, I think it misses the point of *why* class literals are desirable. What you've proposed can already be achieved, with the same "sugar" -- and without introducing a new construct, so people using ES3 can also get it through a library, etc -- by using object exemplars: Selfish, Prototoypes As Classes, etc.
The e-mail Erik pointed has got most of it, though what I really think class literals can bring in that makes them worth is a better and declarative syntax for private/const members and traits. Static shape can be achieved through `Object.freeze', right? I don't think that should be what classes strive to provide. Yeah, static analysis is nice and all, but I believe that goes against the nature of the language's own semantics, and if classes are supposed to be just sugar over prototypical inheritance (with the added benefits I mentioned previously), it makes more sense that they don't make such shape guarantees, imho -- vendors could still optimise for static shape, and fallback to non-optimised code if the instance's shape change, which I guess is what is done today with prototypes(?) and which I think should also be done for `with', but I digress. Still straying a bit from the main subject here, I thought type guards were supposed to be defined at the function level, no? Or is it that the shape of classes would be used to determine the types used? 2011/11/1 David Herman <dher...@mozilla.com> > There may be something wrong with the above -- but dynamic super() should > be a solveable problem for JS.next, even if not entirely desugar-able into > ES3 terms. > > > The problem isn't so much whether it's possible to come up with a > semantics by changing the runtime; I'm sure we could do that. The problem > is finding a way to get the semantics you want without taxing the > performance all other function calls in the language. (Also known as a > "pay-as-you-go" feature: if you don't use the feature, it shouldn't cost > you anything.) We don't know how to do that for super(). > > So I guess in theory I agree it'd be nice if super() and class could be > designed completely orthogonally, but in practice they affect each other. > But at the same time, I think a class syntax where the body is restricted > to be declarative is actually a nice sweet spot anyway. You can still > dynamically create classes just like always, but the declarative form gives > you a sweet and simple syntax for the most common case. > > Dave > Yes, |super| is static to avoid the cost of passing an additional parameter to every function call, whether that uses |super| or not. Object.defineMethod is provided to make functions with bound |super| to other objects. I also think that dynamic |super| makes more sense with JavaScript, but vendors are concerned about performance -- plus, Object.defineMethod should cover the other cases, albeit not as nicely as dynamic |super| would.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
