using Private name objects for declarative property definition.

Brendan Eich brendan at mozilla.com
Fri Jul 8 17:03:05 PDT 2011


On Jul 8, 2011, at 4:21 PM, Allen Wirfs-Brock wrote:

> On Jul 8, 2011, at 3:24 PM, Brendan Eich wrote:
> 
>> Then the shape of the object is not static. Perhaps this is worth the costs to implementations and other "analyzers" (static program analysis, human readers). We should discuss a bit more first, as I just wrote in reply to Allen.
> 
> This is one of the reason I think I slightly prefer the @ approach.  @ can be defined similarly to . in that it must be followed by an identifier and that the identifier must evaluate to a private name object.  The latter in the general case would have to be a runtime check but in many common cases could be statically verified.

This does give a probabilistic edge to implementations optimizing @ for private names only (but with guards that throw on non-private-name result of evaluating what's on the right of @), and predicting or static-analyzing shape.


> Even this doesn't guarantee that we statically know the shape. 

Certainly not. And that is a change from today, which I think we ought to discuss. Because as you note below, private names could be added to objects declared by initialisers that lack any private name syntax, after the initialiser; or after a new Object or Object.create.


>> It does help avoid eval abusage, on the upside.
> 
> If you mean something like:
>     let propName  = computeSomePropertyName();
>     let  obj = eval("({"+propName+":  null})");
> 
> I'd say whoever does that doesn't know the language well enough as their are already good alternatives such as:
>  let obj = {};
>  obj[propName] = null;
> 
> or 
>  let obj = new Object;
>  Object.defineProperty(obj, propName,{value:null, writable: true, enumerable: true, configurable: true});

No, the problem is not that there aren't other ways to do this. Or that people are "too dumb". I've had real JS users, often with some Python knowledge but sometimes just proceeding from a misunderstanding of how object literals are evaluated, ask for the ability to compute property names selectively in object literals.

Sure, they can add them after. That sauce for the goose is good for the private-name gander too, no?


>> Here, with obj = { [expr]: value } as the way to compute a property name in an object initialiser (I must not write "object literal" any longer), we are proceeding up another small and separate hill. But, is this the right design for object initialisers (which the normative grammar does call "ObjectLiterals")?
> 
> Another concern is that it creates another look-ahead issue for the unify blocks and object initializers proposal.

Yes, indeed. I've been thinking about that one since yesterday, without much more to show for it except this: I think we should be careful not to extend object literals in ways that create more ambiguity with blocks.

I grant that the new method syntax is too sweet to give up. But I don't think "{[...", "{!...", etc. for # and ~ after {, are yet worth the ambiguity that is future-hostile to block vs. object literal unity.


>> Agreed that unless we use @ well for both property names in initialisers and private property access, and in particular if we stick with bracketing for access, then square brackets win for property naming too -- but there's still the loss-of-static-shape issue.
> 
> There is also an argument to me made that [ ] and @ represent two different use cases: computed property access and private property access and for that reason there should be a syntactic distinction between them.

Is this different from your first point above, about implementation optimization edge?


>> The original name declaration via "private x" that Dave championed was definitely semantic: it created a new static lookup hierarchy, lexical but for names after . in expressions and before : in property assignments in object literals. This was, as Allen noted, controversial and enough respected folks on es-discuss (I recall Andrew Dupont in particular) and in TC39 reacted negatively that we separated and deferred it. I do not know how to revive it productively.
> 
> Actually, I think you can blame be rather than Dave for the dual lookup hierarchy.  Dave (and Sam's) original proposal did have special semantics for private name declarations bug only had a single lookup hierarchy.

Of course -- sorry about that, credit and blame where due ;-).

/be


More information about the es-discuss mailing list