On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
> On 11/1/11 11:53 PM, Brendan Eich wrote:
>>
>> On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
>>> 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?
>>
>>
> I don't see why you can't use var syntax but with 'proto' as the keyword
> instead of 'var':
I lean toward (a) now. I've made my peace with object initialiser syntax -- but
with the Cordoba extensions for classes and object literals, as discussed with
Jeremy today.
>>> Your private instance variables are quite interesting.
>>
>> Yes, that is a missing ingredient in most proposals we've seen.
>>
> And inquiring minds want to know more about them. I assume they're scoped to
> the entire class body, right?
Certainly.
> And they hoist to the top?
That's how we roll where possible.
> Could they have initializers that were automatically included in the
> constructor?
I answered that in a gist comment. Yes, I like the CoffeeScript constructor(@x,
@y){} shorthand. Dart picked up on it, but requires this. instead of @. I'll
put it in the gist.
> A comment in your gist (lines 186-187) seems to say that with 'private x', we
> can use @x or this[x]. Is that really what you meant?
Sorry, not quite. I will fix that comment.
> Plain 'x' is bound to the Name object and @x is the value of the property
> with that name? Is x a variable?
x is a const binding in the "@ scope" of the class body. It does not collide
with any lexically bound x (formal parameter name, e.g.). That's important --
see the Monster constructor with its name and health parameters and private
property names.
So, o@x is *not* o[x] for such a private-declared x.
Some argue @ should work for any x, so if there were some x = "y" in scope,
then o@x would be o[x] would be o.y. I think that's too error-prone. What if I
typo @heath instead of @health and there's a non-private-declared heath in
scope?
> Does this mean that the class desugars into something that has a let
> statement surrounding the all the methods?
No, because private x does not bind a lexical name 'x' usable freely.
private/@ is new, the semantics are a slight extension to today's, not
desugarable without gensym. I'll consult with my semantic betters on this one.
>>> 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.
>>
> I think ordinary unary @ would dominate and .@ would be relatively rare. But
> when used, it would at least look like noisy property access rather than an
> email address. My gut says that regularity of syntax wins over
> conciseness and noise here.
Oh, I see -- you are suggesting @x as short for this.@x, and requiring other.@x
for non-this-based references. That could work. IINM it even avoids the [no
LineTerminator here] to the left of unary prefix @. Nice!
I hear you on the email thing. I'm big on grep, and I mourn the coming demise
of codesearch.google.com.
> Do you expect the performance of private property lookup to be equivalent to
> public property lookup? That is will @foo take the same time as this.foo?
That is a requirement in my view.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
