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).
https://codereview.chromium.org/352173004/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
