[Harmony classes] method lexical scope for InstancePropertyDefinitions, PrototypePropertyDefinitions?

Gavin Barraclough barraclough at apple.com
Wed Jun 15 19:16:53 PDT 2011


On Jun 14, 2011, at 3:27 PM, Brendan Eich wrote:
> On Jun 14, 2011, at 2:45 PM, Gavin Barraclough wrote:
> 
>>       return x * y * z;
> 
> This works for the public instance properties, but IIRC some folks object that it is too easy to make mistakes vs. formal parameters of the same name.

Understood.  It seems unfortunate to me to restrict the language syntax here to dictate what really seems to be an open question of coding style.  Choosing to prefix all member property access with 'this.' in an attempt to avoid such mistakes certainly seems a reasonable position for a programmer to take, however I don't think it's clear that this is the only possible correct decision.  A devil's advocate argument might be that the unnecessary verbosity this introduces may make the code less readable, and increase the difficulty for a developer to spot bugs.  I don't wish to start a debate on what the right style is here; rather to suggest that we shouldn't be taking a position on either side.

It would seem possible that if we stick with the current proposal and member properties are not in lexical scope, then this may be something that would have to be revisited in a later revision of the language, should developers report the syntax to be overly verbose.  If this is the route we go down, do you think perhaps it might be worth trying to reserve space in the language such that there would be room for backwards compatible changes here?  For example, might there be any value in considering poisoning these Identifiers, such that a resolve of an Identifer matching the name of an instance property from inside a method is a syntax error?

>>   public weight()
>>   {
>>       return this.volume() * density;
>>   }
> 
> Here's the killer. density is private. Yes, in this case there can be no other density, but the Point equals method that needs to use p at x and p at y or private(p).x and private(p).y to compare to the other (argument) point p must have new notation for referring to the private instance variable of the other maybe-instance.
> 
> Same if you had a compareDensity(otherBox) method here.
> 
> Given this, putting the private in scope is helpful for self-references but not for other-refs, and it is a bit misleading.

Well, I guess there is a simple solution to that problem, though it introduces an asymmetry that I'm not sure you'll be keen on. :-)

Within methods on classes, where ever the Identifier on the RHS of a dot access MemberExpression matches the name of a private property defined in the class, we could always assume this this will be a private property access.  This would allow private property access with no additional syntax.  In cases where it is necessary to access a public property on an object that has a name aliasing a private member on the current class, bracket access syntax could be used (and a programmer could chose to avoid this problem through naming conventions if they wished to do so, e.g. prefix all private instance property names to prevent conflicts with public properties).

On the topic of p at x, p at y, I find that syntax a little weird since the @ sign reads backwards to me - with an @ I naturally expect the property to be on the left, and the thing that owns it on the right.  E.g. brendan at mozilla.com - mozilla.com is an object that has a property called brendan. ;-)

> Similarly, if prototype property definitions were brought into scope we could omit the 'this.' on the call to volume:
>> 
>>   public weight()
>>   {
>>       return volume() * density;
>>   }
> 
> Object != scope. We do not want mutable objects on the scope chain. We don't want any objects on the scope chain, really. This goes for modules too, they are closed for a reason.

Just to clarify I'm only proposing bringing methods on the prototype into the lexical scope of a method where they are defined in the class declaration with a PrototypePropertyDefinition; this would be a purely lexical desugaring rather than introducing the prototype object onto the scope chain.

cheers,
G.



More information about the es-discuss mailing list