On May 19, 2011, at 4:24 PM, Mark S. Miller wrote: > http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#member_declarations_and_definitions > is light on details, but I took these to define local bindings usable in > other ClassElements -- not to create prototype properties (or any kind of > property on an object). > > Did I miss something? > > Yes. An unannotated Declaration defines a prototype property of that name. > > class Point { > const x = 0; > //... > } > > defines a non-writable, enumerable, non-configurable "x" property on > Point.prototype, as if by > > Object.defineProperty(Point.prototype, 'x', { > value: 0, writable: false, enumerable: true, configurable: false > });
I see. Then a couple of thoughts: 1. The Declaration production being used here, when used in Statement contexts normally binds names lexically. Here it binds prototype properties. This is not consistent in a sense we might want to make consistent. Allen's http://wiki.ecmascript.org/doku.php?id=strawman:concise_object_literal_extensions strawman provides initialiser extensions for controlling writable, configurable and enumerable. 2. In this light, I do see the value of var instead of const: prior to Harmony, var at top level binds a writable, enumerable, non-configurable global property. True, Harmony gets the global object off the scope chain, but the precedent is there. Taken together, I wonder whether we aren't abusing Declaration to bind properties. >> That said, if we decide we really want a keyword here and can't come up with >> a better alternative than "var", I probably could be talked into it. And I'm >> happy to see this added as an option to the strawman. > > I'm still not sure we need to bind (enumerable by default, I just noticed -- > a for-in hazard) data properties on the class prototype. > > I agree that data on the prototype is comparatively rare. But symmetry and > consistency sometimes lead us to supporting rare cases, merely to avoid > introducing special cases that prohibit them. Sure, although mixing declaration syntax with property initialiser syntax in class body context invites two conflicting dimensions of consistency. That again makes me wonder whether class body should not consist only of property initialiser variants including methods and constructors. In particular, given method initialisers, why support function declarations as well? Also, are nested classes best bound to prototype properties? class A { class B {} ... }; a = new A; b = new a.B; ... is consistent along one dimension but it expresses something super-rare in the prototypal pattern used today, in my view unheard of. An alternative to property initialisers only, one Dave and I misunderstood the strawman to be proposing: declarations, as opposed to initialisers, bound temporaries once in the lexical scope of the class body, for use by methods and other nested forms. In other words, implicitly private class static bindings. Was this considered? The simplest idea would be initialisers only, and I know that created a commas-not-semicolons confusion, but that could be changed. Class bodies are neither exactly initialiser nor function bodies, but they might rather be initialiser-like with ; instead of , where a braced body does not terminate the element. > As a ClassElement, "x = y;" is just shorthand for "let x = y;". Likewise > "static x = y;" is just shorthand for "static let x = y;". Except let binds lexically in other declarations. This seems an aesthetic/philosophical objection -- we can make let mean what we like in class body context -- but it also smells bad to me. You? > Also, Gilad Bracha has shown many cool patterns in Newspeak leveraging the > ability to inherit a default nested class but being able to override it by a > like-named nested class in a subclass. Once you get used to it, it's actually > much more natural and expressive than static nested classes. I think I read Gilad's blog on that a while ago, I'll have to re-read. Again, though, there is nothing like this in idiomatic prototypal JS that I've seen. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
