Proposal: Object.defineProperty shorthand

Sean Eagan seaneagan1 at gmail.com
Fri May 27 18:16:50 PDT 2011


Sorry Mike, just saw your response.  I think it would use the same
parsing technique as destructuring, the left hand side would need to
be post-processed.  My grammar might need to be updated to make that
work though.

The pattern matching strawman [1] has a note about this:

Destructuring assignment is parsed as an LHSExpression but then
post-processed as a Pattern(false). Note that this non-terminal
represents a subset of LHSExpression.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching

On Thu, May 26, 2011 at 4:06 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> On Thu, May 26, 2011 at 11:54 AM, Sean Eagan <seaneagan1 at gmail.com> wrote:
>> On Thu, May 26, 2011 at 1:43 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
>>> On Thu, May 26, 2011 at 11:37 AM, Sean Eagan <seaneagan1 at gmail.com> wrote:
>>>> // ! implies non-writable, ~ implies non-enumerable
>>>> // all assignment operators can be used
>>>> ! a.b += c
>>>
>>> Legal parse today, though I'm not sure you can get runtime semantics
>>> that aren't an error.
>>
>> Correct, I was intending for it to no longer be an error.
>
> I don't understand how that could work.  By the time you get the
> runtime error (trying to increment a boolean value), we have already
> performed a property access, which can have side-effects.  More
> practically, an engine would have to reconstruct the original
> syntactic form from the runtime result.
>
> addto(c, not(get(a, "b")))
>
> Mike
>


Thanks,
Sean Eagan


More information about the es-discuss mailing list