On 29 August 2012 18:39, Allen Wirfs-Brock <[email protected]> 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.@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.@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 .@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. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
