new strawman: syntactic support for private names

Andreas Rossberg rossberg at
Fri Aug 31 00:53:00 PDT 2012

On 29 August 2012 18:39, Allen Wirfs-Brock <allen at> wrote:
> There are been various previous runs at defining syntactic support for using
> unique/private names.  They all run into either real or hypothetical
> usability issues that blocked adoption. One consistent area of concern has
> been contextual variation in the use of a sigil such as @.  For example:
> private member;  //(no sigil) user just wants to think of "member" as a
> restricted visibility property key.
> let obj = {@member: 42};     //they have to remember to use the sigil here
> because this is a context where identifiers are implicitly quoted
> let fortytwo = obj[member];  //must not use the sigil here
> alert(obj. at member);           //need to remember to use the sigil here ,
> obj.member would meaning something completely different.
> In the above scheme, there is nothing that syntactically identifiers a bound
> name that is intended to use as a restricted property key.  The sigil is a
> syntactic element of the usage context.  Some contexts require one, others
> do not.  A user has to mentally track which identifiers hold property keys
> and and remember in which contexts a sigil is required or must be avoided.
> In my proposal, I attempt to simplify this by making the sigil part of the
> actual identifier.  At the point of declaration, you decide that a certain
> identifier is going to be used to represent a unique name property key. This
> decision is reflected in the actual identifier because it must be prefixed
> with the @.  It is also a immutable binding. It's value is guaranteed to be
> name object that was originally associated with it. All subsequent uses of
> the identifier must also be prefixed.  There is never any confusion about
> where you are referring to name object based property name or to a string
> property name. You don't have to remember which context are quoting and
> which are not.
> This seems simple, to me.

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

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?

Second, the proposal effectively destroys the first-class nature of
@names, because you can only bind them fresh via special declarations,
not to the result of some computation. That is, unless you also allow
name alias declarations

  name @foo = expr

to recover the special syntactic status for a computation's result
(i.e., the counterpart to allowing @foo as a free-standing
expression). In other words, I think support for name alias
declarations has to be an integral part of the proposal, not an
optional one.


More information about the es-discuss mailing list