Status: Available
Owner: ----
CC: [email protected], [email protected], [email protected],
[email protected], [email protected]
Labels: Type-Bug Priority-Medium Area-API
New issue 4334 by [email protected]: API: Should CreateDataProperty
overwrite accessors, or call them?
https://code.google.com/p/v8/issues/detail?id=4334
Tracking bug to figure out whether v8::Object::CreateDataProperty should
call or overwrite an existing API-style accessor for the property in
question.
I've found https://codereview.chromium.org/1173283004/ which appears to
intentionally restore accessor-overwriting behavior for ForceSet (which is
deprecated) and accessor-calling behavior for CreateDataProperty.
Unfortunately it doesn't convey any rationale.
CreateDataProperty's header comment says it implements EcmaScript's
CreateDataProperty
(http://www.ecma-international.org/ecma-262/6.0/index.html#sec-definepropertyorthrow),
which calls [[DefineOwnProperty]], which should overwrite an accessor with
a data property (if it's configurable).
haraken@ says that accessor-overwriting behavior is what the Blink-V8
bindings want, in order to be able to replace ForceSet.
There doesn't seem to be any non-deprecated way in the API to replace an
API-style accessor, short of deleting it explicitly and then adding a new
property, which is probably not a usage pattern we want to encourage.
Am I understanding things correctly? Are there any reasons to continue to
let CreateDataProperty call accessors instead of overwriting them?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
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.
