Proposal: Object.defineProperty shorthand

Sean Eagan seaneagan1 at
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.


On Thu, May 26, 2011 at 4:06 PM, Mike Shaver <mike.shaver at> wrote:
> On Thu, May 26, 2011 at 11:54 AM, Sean Eagan <seaneagan1 at> wrote:
>> On Thu, May 26, 2011 at 1:43 PM, Mike Shaver <mike.shaver at> wrote:
>>> On Thu, May 26, 2011 at 11:37 AM, Sean Eagan <seaneagan1 at> 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

Sean Eagan

More information about the es-discuss mailing list