Relax object literal checking to follow ES6

Relax object literal checking to follow ES6

R=marja@chromium.org, rossberg@chromium.org
BUG=

[wingo, 2014-06-25 16:08:37]

PTAL; an early RFC patch for comments.  Some more tests are needed for
accessor/data duplicate property interactions.  I propose not doing this change
behind a flag; wdyt?

[rossberg, 2014-06-26 15:55:12]

On 2014/06/25 16:08:37, wingo wrote:
> PTAL; an early RFC patch for comments.  Some more tests are needed for
> accessor/data duplicate property interactions.  I propose not doing this
change
> behind a flag; wdyt?

Hm, why is the complication necessary? Can't we just do something really simple
and generic in the case where there actually is a duplicate? Doesn't matter that
it would be slow.

[wingo, 2014-07-02 13:39:38]

On 2014/06/26 15:55:12, rossberg wrote:
> On 2014/06/25 16:08:37, wingo wrote:
> > PTAL; an early RFC patch for comments.  Some more tests are needed for
> > accessor/data duplicate property interactions.  I propose not doing this
> change
> > behind a flag; wdyt?
> 
> Hm, why is the complication necessary? Can't we just do something really
simple
> and generic in the case where there actually is a duplicate? Doesn't matter
that
> it would be slow.

I don't really see a way to do this.  If you want an abstraction between:

 (1) the existing code where you can use a boilerplate object with pre-filled
constant values, just emitting code to set things at runtime when needed, trying
to collect getters and setters to avoid having to look up a getter at runtime
when adding a setter and vice versa, and:

 (2) a translation to "do () { var o = {}; o.foo = 20; o.bar = 30; o }"

If this is what you want, then you have to represent some of the aspects of (1)
in the generic solution.

Particularly with duplicate properties we run into tricky semantic corner-cases.
 For example:

  ({ get foo() { 42 }, foo: 10, set foo(x) { ... } })

What does the resulting object look like?  It has one property, "foo", and it's
an accessor property, but does it have a getter?  (In the above patch: it does
not have a getter.  However,-writing to es-discuss to clarify has not been
useful.)

Likewise:

  ({ get __proto__() { 42 }, __proto__: 10, set __proto__(x) { ... } })

Clearly the __proto__:10 sets the [[Prototype]].  But does it have a getter? 
The state machine in ast.cc provides a fairly simple (though regrettably
verbose) way to answer these questions once in a central place, which I find
more better than the current state of things ;)  It's also easy to extend to the
computed property name case, with no impact on code generation either (except
taking out some UNREACHABLE()s).

[wingo, 2014-07-02 14:06:21]

On 2014/07/02 13:39:38, wingo wrote:
> verbose) way to answer these questions once in a central place, which I find
> more better than the current state of things ;)  It's also easy to extend to
the

This post may contain logical errors, but I put in this "more better" to
distract you :)

[rossberg, 2014-07-02 14:08:26]

On 2014/07/02 13:39:38, wingo wrote:
> On 2014/06/26 15:55:12, rossberg wrote:
> > On 2014/06/25 16:08:37, wingo wrote:
> > > PTAL; an early RFC patch for comments.  Some more tests are needed for
> > > accessor/data duplicate property interactions.  I propose not doing this
> > change
> > > behind a flag; wdyt?
> > 
> > Hm, why is the complication necessary? Can't we just do something really
> simple
> > and generic in the case where there actually is a duplicate? Doesn't matter
> that
> > it would be slow.
> 
> I don't really see a way to do this.  If you want an abstraction between:
> 
>  (1) the existing code where you can use a boilerplate object with pre-filled
> constant values, just emitting code to set things at runtime when needed,
trying
> to collect getters and setters to avoid having to look up a getter at runtime
> when adding a setter and vice versa, and:
> 
>  (2) a translation to "do () { var o = {}; o.foo = 20; o.bar = 30; o }"
> 
> If this is what you want, then you have to represent some of the aspects of
(1)
> in the generic solution.
> 
> Particularly with duplicate properties we run into tricky semantic
corner-cases.
>  For example:
> 
>   ({ get foo() { 42 }, foo: 10, set foo(x) { ... } })

My understanding of the proposed semantics is simple left-to-right calls of
DefineProperty (i.e., what the draft already prescribes, but minus the static
checks). That is, the above would desugar into an equivalent of

  do {
    let o = {}
    Object.defineProperty(o, 'foo', {get: function() { 42 }, configurable: true,
enumerable: true})
    Object.defineProperty(o, 'foo', {value: 10, writable: true, configurable:
true, enumerable: true})
    Object.defineProperty(o, 'foo', {set: function(x) { ... }, configurable:
true, enumerable: true})
    o
  }

Hence, the resulting object only has a getter.

I had hoped that this would be easy to achieve by skipping boilerplates and
instead dumbly calling the appropriate runtime functions in order for any object
literal where we cannot statically determine the property names or their
disjointness.

But I may be convinced otherwise. :)

> What does the resulting object look like?  It has one property, "foo", and
it's
> an accessor property, but does it have a getter?  (In the above patch: it does
> not have a getter.  However,-writing to es-discuss to clarify has not been
> useful.)
> 
> Likewise:
> 
>   ({ get __proto__() { 42 }, __proto__: 10, set __proto__(x) { ... } })
> 
> Clearly the __proto__:10 sets the [[Prototype]].  But does it have a getter? 

Yeah, this one is uglier, but I would extrapolate that the magic __proto__ value
property is treated specially and simply filtered out of the sequence of regular
properties. So the object would have both getter and setter.

> The state machine in ast.cc provides a fairly simple (though regrettably
> verbose) way to answer these questions once in a central place, which I find
> more better than the current state of things ;)  It's also easy to extend to
the
> computed property name case, with no impact on code generation either (except
> taking out some UNREACHABLE()s).

[wingo, 2014-07-02 15:11:05]

On 2014/07/02 14:08:26, rossberg wrote:
> On 2014/07/02 13:39:38, wingo wrote:
> >   ({ get foo() { 42 }, foo: 10, set foo(x) { ... } })
> 
> My understanding of the proposed semantics is simple left-to-right calls of
> DefineProperty

Interesting, I didn't realize that Object.defineProperty(o, 'foo', { get: fn })
would inherit the corresponding setter.  Thanks for pointing that out.

> I had hoped that this would be easy to achieve by skipping boilerplates and
> instead dumbly calling the appropriate runtime functions in order for any
object
> literal where we cannot statically determine the property names or their
> disjointness.
> 
> But I may be convinced otherwise. :)

Sure; I'll give it another go.

> >   ({ get __proto__() { 42 }, __proto__: 10, set __proto__(x) { ... } })
> > 
> > Clearly the __proto__:10 sets the [[Prototype]].  But does it have a getter?

> 
> Yeah, this one is uglier, but I would extrapolate that the magic __proto__
value
> property is treated specially and simply filtered out of the sequence of
regular
> properties. So the object would have both getter and setter.

OK, sounds fine to me.