new strawman: syntactic support for private names
rossberg at google.com
Fri Aug 31 11:40:39 PDT 2012
On 31 August 2012 19:39, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On Aug 31, 2012, at 12:53 AM, Andreas Rossberg wrote:
>> Two observations. First, IIUC, separate namespaces mean that I can _not_ write
>> let foo = new Name
>> o. at foo = 1
>> anymore. For first-class names, I would have to fall back to
>> o[foo] = 1
> Yes, that is an intentional part of this design. The concept is that @names are similar in usage to immediate values, but ones that have to be explicitly introduced via a declaration.
>> Wouldn't that reintroduce the very problems we tried to avoid by
>> considering . at foo as a syntax separate from [foo] in the first place,
>> i.e. confusing named property access with indexing collections?
> In my proposal . at foo isn't separate syntax. It's a dot, followed by a @name. A simplified version of the grammar as:
> MemberExpression :
> MemberExpression [ Expression]
> MemberExpression . PropertySelector
> PropertySelector :
> PrimaryExpression :
> So, there is technically no confusion between property access and indexing collection. Dot and Index access have distinct syntax and semantics. The point of potential conceptual confusion is that AtName used as a PropertySelector and AtName used as a Primary expression evaluate in exactly the same way. This is different from IdentifierName which has different evaluation rules for those two contexts.
> We can't treat At-Names in PropertySelector contexts just like IdentifierNames, because in that case an expression like obj. at foo] would means the same thing as obj["@foo"] which is not what we are trying to accomplish. Note, that we would have similar behavior if we allowed string constants to appear immediately after a dot. EG
> Basically, within the scope of a name/private declaration the best way to think about an AtName is as an immediate representation of its value rather than a variable reference.
> I agree this is anomalous, relative to the handling of IdentifierNames but there has to be a anomaly somewhere if we are gong to allow dot property access using unique/private names. In practice, I see little reason for anybody every wanting to say o[@foo] rather than o. at foo. So, I expect people will seldom encounter this anomaly.
Ah, I actually meant something else. You had a proposal to allow
indexing via  to be treated differently from dot projection, and
allow the user to redefine it for implementing new collection types.
That implies that in the future, it generally is no longer the
appropriate operation to use  to set actual attribute properties (as
you usually want to do with private names).
However, with your proposal, it seems necessary to use  when I want
to set a property with a name that is not statically "known" (i.e.,
perhaps the result of a computation).
let foo = getMyUniquePropertyName()
userCollection[foo] = myUniquePropertyValue
may not have the right meaning, and it is different from what
name @foo = getMyUniquePropertyName()
userCollection. at foo = myUniquePropertyValue
would mean. But the latter probably was the intention.
In other words, if you intend to separate access to collection
elements from access to object properties in future ES (which I think
is a good idea), then we shouldn't rely on using  to use private
properties. But that is the case in the strawman.
More information about the es-discuss