Comment #2 on issue 4334 by [email protected]: API: Should
CreateDataProperty overwrite accessors, or call them?
https://code.google.com/p/v8/issues/detail?id=4334
API accessors entirely behave like data properties, with the data
management handled by the accessor. If we don't call the accessor in
DefineOwnProperty, this subverts the accessor.
E.g. [].length is handled internally by an API accessor. If we'd just
replace it with a data property, we'd all of a sudden have 2 lengths. The
length internally stored by the accessor in a hidden field, and the newly
added data field. Both can be out-of-sync. We previously had this exact
situation, which is pretty bad. Subsequent stores to "length" (if still
possible) would break JS semantics; and possibly even lead to security
issues.
The problem is though that API accessors always worked that way, up to the
point that blink and other clients relied on this implementation. They
use(d) it as a feature to lazily compute and install data properties. Hence
ForceSet needed to support removing the API accessors and replacing it with
a real data property. The better alternative, requiring blink changes, is
to keep using the accessor and store the data property as an internal
field. This is slower though. If this is still necessary in the future, we
might want to extend the API with a new kind of "lazy data property" so
that we at least know what the API is trying to do.
This was only true through ForceSet though. Object.defineProperty available
to JS did not expose the same API. CreateDataProperty is basically
Object.defineProperty for data properties with default NONE attributes.
Hence we shouldn't use the flag passed in by ForceSet. Meaning, we should
always call the setter to store the property.
I don't fully understand the second part of your question though, starting
from haraken@ says. I'll just guess what you're asking:
In blink they are replacing old-style API accessors (that look like data
properties) with real accessors. At that point it definitely does not make
sense anymore to call the setter, but we just reconfigure.
CreateDataProperty *will* reconfigure as long as the property is
configurable, exactly what you want. In that case you go from ACCESSOR /
AccessorPair to DATA. Not from ACCESSOR / ExecutableAccessorInfo (which
looks like DATA from JS) to DATA. That's (very obviously ... ;)) entirely
different.
--
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.
