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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
