About private names

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Mar 20 17:01:41 PDT 2011


On Mar 20, 2011, at 4:20 PM, Dean Landolt wrote:

> I think you're missing the distinction. The obj["foo"] example is just a stand-in for `var foo="foo"; obj[foo]` -- we would all expect the string key lookup to be the same as obj.foo, and anything less would be a bit surprising. This is what Andrew was reacting to.
> 
> The relationship between bracketed string lookup and dot lookup is, for now, very clear and predictable

I don't see any dot lookup above so I'm not sure how the above assertion follows form the example.  In general if you see obj[foo] and obj.foo without knowing the value of the variable foo you can't make any assumptions about the whether or not they will access the same property.

Private names changes nothing about this.  If you know the value of a variable or expression used to produce a property lookup key then you know what property will be access.  If you don't know what value is going to be produce then you cant make any correlation to a property access using a known literal value.


> -- private names muddies it up a bit. Perhaps a big bold warning about this is enough to realign developer expectations, I couldn't say. But whether you'd ever do a bracketed string-literal lookup is beside the point.

The most important part of the private name proposal is that it expands the domain of value that can be used as property keys to include certain non-string values.  This these are property names that do not have literal representations either as quoted strings or identifiers that are treated as literal string value.

This could be supported without any changes to the surface syntax or semantics of the core language via a built-in constructor:

var nonStringName1 = new PrivateName;  //generate a unique property key

var obj= { }; 
obj[nonStringName1] = 1;
print(obj[nonStringName1]);  //1
print(obj["nonStringName1"); //undefined
functionDefinedElseWhere(obj);  // won't be able to access the property because it doesn't know its name

We could stop here and some may reasonably argue that we should.  The rest of the private names proposal is about enabling the use of dot notation with of non-string valued private names and also (and probably more important) the definition of properties wit such names in object literals.

Allen


More information about the es-discuss mailing list