Proposal: Object.defineProperty shorthand
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
The pattern matching strawman  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 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")))
More information about the es-discuss