On Jul 6, 2011, at 3:19 PM, Allen Wirfs-Brock wrote:
> So, a next step is to look at this in combination with other Harmony
> proposals. In particular, the object literal extensions.
Yes, I've been dividing and conquering ;-). Thanks for the followup.
> There is one pretty obvious ambiguity introduced by the methods property
> shorthand.
>
> Keep mind that property names are permitted to be keywords. So
>
> let ambig1 = {function () {}}; //object with method named 'function' or 0
> argument lambda that returns a function object?
Never the latter, anonymous function expressions are not produced by Statement.
> let ambig2 = {if (x) {5}}; //object with method named 'if' or 0 argument
> lambda that returns either 5 or undefined depending value of free variable x?
Quite.
> I don't think we want to loose the conciseness of method property shorthand,
> but I we can resolve this one by restricting the property name to being an
> identifier rather than an identifierName in the method property shorthand.
> Presumably if you really wanted to have a method property named function or
> if (or any other keyword) you could use a StringLiteral property name in the
> object literal:
>
> let obj1 = {"function" () {}}; //object with method named 'function'
> let obj2 = {"if" (x) {5}}; //object with method named 'if'
>
> However, are we going to have lookup issues with StringLiteral and
> NumericLiteral method property name? "if"(x) or 123() are syntactically valid
> call expressions so we have to see the { after the ) before we know it is an
> object literal and not a block lambda.
Lookahead issues, yes.
> Property value short hand is also a problem:
>
> let x=2;
> let ambig3 = {x}; //is this an object literal equivalent to {x:x} or a 0
> argument block lambda that returns the value of x?
That one is noted already in arrow function syntax.
> I don't see a easy way to resolve this one other than dropping property
> value shorthand. I'd be willing to sacrifice them in order to get block
> lambdas
Block lambdas as proposed don't have any ambiguities because they require empty
|| parameter lists for the zero-parameter case.
> I don't think the ! and ~ property attribute prefixes cause any ambiguity
> issues:
>
> let obj3 = {~x: 5};
> let obj4= (!z(a,b,c,d) {}};
>
> however, it does further increase the lookahead necessary be decide between
> an initial method property or an initial expression statement. This might be
> enough to reexamine the use of these attribute prefixes.
The lookahead requirement is a problem for LR(1) validation, which I'm
skeptical we can or should step away from.
> I still think we need attribute control functionality in object literals
> but I think I would be willing to give up on them for the method property
> shorthand if that would help. Essentially say that you have to use an
> old-fashioned property : property assignment if you want to specify
> non-default method attributes:
>
> let obj4={!z: function(a,b,c,d) {}};
Could the attribute punctuators go after the property name instead of before?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
