On Nov 2, 2011, at 3:08 PM, David Flanagan wrote:
> On 11/2/11 11:16 AM, Brendan Eich wrote:
>> On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
>>
>>
>>> 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.
>>
>>
> I saw the comment, I think. What I meant here was initializer expressions
> that are part of the 'private' declaration. That is, can I write
>
> private stack = [];
>
> and have that initialization code automatically inserted (Java-like) into the
> constructor for me? I'm trying to understand whether private and static have
> the same basic syntax in this proposal.
The problem with initialization of private vars outside of the constructor is
the order dependency. Do private names with initializers get bound and
initialized before entry to the constructor, independent of their order with
respect to the constructor in the class body? I hope so, but that might seem
confusing. Can an initializer refer to the value of a prior name, e.g.
private stack = [], stack2 = @stack;
My gist does not show initializers for private names, and since I switched to
object literal syntax with optional prefix keywords, the above should be
private stack: [], private stack2: @stack, ...
That is, no ; at end, and private must be repeated as a property initialiser
prefix (which sucks).
An alternative mentioned in some comments is to allow @name: value, and
@method() {...}, to be used in class bodies to bind private names without
having to pre-declare them with private name, method; declarations or the like.
That avoids the problem but only if you are willing to initialize prototype
private-named properties -- that's what these initialiser parts do.
If you want to declare private names in scope throughout the body (in all
methods), initailized in the constructor via @name = value; assignment
expression-statements, then you want something like a private name;
declaration. But the declaration-style syntax, with semicolon at end, is at
odds with the main object literal flow.
>>> 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.
>>
> What I don't understand is whether the "@ scope" is a specification
> abstraction, or whether it is visible to programmers. If I declare a private
> variable x, and there isn't any other x in scope, is x bound to a Name object
> that I can use?
Only via @ -- not in other expressions or you collide @health and health.
> If not, is there any way I can access the automatically-created Name objects
> so that I can share my private names with "friend" classes?
No, not in what I'm proposing. If you want that, you'll have to Name.create().
>> 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?
>>
> That's where a 'public' declaration comes in! 'private x' binds x to a new
> Name in @ scope. And 'public y' binds y to "y" in @ scope. Then make @ work
> with any identifier declared private or public. That would allow programmers
> to elide the "this" but still have publicly visible properties.
Ok, that seems unproblematic at first glance.
> Resolution of identifiers in @ scope can happen at compile time, can't it?
Requirement!
> That is, for the code "@x", x is just looked up in @ scope once when the
> code is compiled, not dynamcally each time it is evaluated, right?
Absolutely.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
