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

Brendan Eich brendan at mozilla.com
Wed Jun 15 21:42:23 PDT 2011


On Jun 15, 2011, at 7:16 PM, Gavin Barraclough wrote:

> 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.

I should have mentioned the same issue that applies to putting the prototype on the scope chain: you're essentially asking for the same trouble here, but with the instance (this) object. The properties may be deleted -- then what does x mean? An outer x binding shining through?

Classes are sugar for prototypal inheritance, including instance properties that are really properties in an object -- not required to be non-configurable.


>  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.

Let's ignore the ocnfusion issue, sorry I brought it up. The problem is putting an object on the scope chain.


> 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.

Developers have to deal with "this." (and "other.") today -- wherefore CoffeeScript's @ operator.


>  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?

So long as these are instance properties and not immutable fields of some kind (we had those for ES4, we called them fixtures -- they were a lot like non-configurable accessor properties are now), we have a prior problem. We cannot reserve as lexical bindings identifiers naming configurable properties on the receiver.


> 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.

That would be a big mistake. Not gonna happen. Onerous for common identifiers (consider the canonical "draw" method on Cowboy and Sprite) used differently by different abstractions.


>> 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.

I don't know what you mean by "lexical desugaring". That suggests rewriting protoMethod in a prototype-enclosed method to be this.protoMethod or some such expression -- bug again, the protoMethod is in general configurable -- it can be deleted. This is *not* lexical in any sense.

/be


More information about the es-discuss mailing list