On Nov 1, 2011, at 10:27 PM, David Flanagan wrote: > [Oops. Replied to Brendan personally rather than reply-all to the list.]
My reply was private too. Here it is: On Nov 1, 2011, at 10:15 PM, David Flanagan wrote: > On 11/1/11 5:18 PM, Brendan Eich wrote: >> >> Love it or hate it, I'm ok either way :-P. But I do crave intelligent >> responses. >> >> > I think reusing var and const in this context will be considered a wart on > the language. If I've got to prefix an identifier with 'this' then it is a > property, not a variable or a constant. We all know that global variables > are properties of the global object, but we don't think of them that way. > They're still just global variables. So I don't think that "cat's out of the > bag" argument for using them here flies. Yeah, sure -- global object is not on scope chain in Harmony anyway. My point was less technical than metaphorical -- and note how Dart uses var (C# too). > I've got four alternatives to suggest: > > 1) Class bodies are new syntax, so you can introduce new keywords, right? So > 'prop' or 'proto'? 'static' puts a property on the class. 'private' puts a > (private) property on the instance. So 'proto' could put a property on the > prototype. Yes, but prefix keywords in front of every member? Too heavy. Labeled sections are problematic grammatically and most on TC39 hate 'em. prefixed braced sub-bodies over-indent. There ought to be a sane unprefixed default. Then, though, we still have two choices: (a) Data property initialiser syntax (x: v with comma separator). (b) Assignment expression form (x = v with semicolon separator or terminator and some kind of ASI consistency). Neither is great. I lean toward (b). You? > 2) As others have suggested, use 'public' and 'public const' instead of 'var' > and 'const'. I'd prefer that 'public' be like 'private' and define an > instance variable (see below), though, so I don't really like this > alternative. Agreed. Also, you can't initialize instance variables at the class body element level. > 3) Most classical OO languages just have instance properties and class > properties. This distinction between instance properties and prototype > properties is a JavaScript thing. Kind of -- although are methods "instance properties" in other OO languages? Not quite. They're in a shared singleton-per-class vtable or the like. > And if we're trying to emulate classical OO, then how about just dropping the > ability to define data properties on the prototype. I am all for that! I kept it for parity with jashkenas's three.js example, but the r, g, and b props there are vacuous default proto-props (ditto the Monster example's proto var and const). > 4) Do your class bodies allow getters and setters? Sure, they're easy. Left 'em out for parity and brevity. They follow the property initialiser in object literal pattern. > Your private instance variables are quite interesting. Yes, that is a missing ingredient in most proposals we've seen. > One nit: you're using @ as both a sigil in @name and as an operator in > other@name. I would expect other.@name instead. No, it's a prefix operator if in operand context (like / starting a regexp), a binary operator in operator context (/ as division). Trying to avoid .@ all over, and this.@ noise. > And a question: do we really need both the private declaration and the sigil? Yes. Otherwise the private declaration takes over all dot references of any such name, and that's wrong. We have no static types to consult, so we have to use a different sigil/operator. Note @ in Ruby for instance-private ivars. You have to message an "other" parameter to get its x and y (if it's a point) or have that message send fail at runtime -- or check its type in your dyadic method and double-dispatch, etc. > But more to the point, you've defined a syntax that allows us to drop 'this' > from our methods! That's seriously cool. Only for private vars. > So cool that I expect using private properties will become the default and > normal public properties will be the exception. Unless... Can you also allow > 'this' to be dropped for public instance variables? With a 'public' > declaration and/or a different sigil? We could use the same sigil/namespace, but then public and private names could collide and that seems future hostile. I may have API growth where a common name I've used for a private is now required for a public in order to interface to some third party code. > What about just a dot with nothing on the left hand side? Can '.foo' be > shorthand for 'this.foo'? Or are there grammatical issues with that? That could work with [no LineTerminator here] restriction on the left, which is awkward -- it mandates manual semicolon insertion of you assign .foo = bar after a baz() statement. We thought about this in consider how to reform with, but that's a dead end. Another sigil is hard to justify for the this.publicProp case, and for dyadic methods, etc., other.publicProp is how you spell it -- the dot, I mean. So one would want this.publicProp anyway. Between this consideration and the preference for private, I'm fine stopping with @ for private. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
