Le 16/06/2011 17:46, Mark S. Miller a écrit :
On Thu, Jun 16, 2011 at 8:29 AM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
Le 16/06/2011 16:50, Tom Van Cutsem a écrit :
2011/6/16 Mark S. Miller <[email protected]
<mailto:[email protected]>>
Ok good, I'll take you up on that. I propose that ES-next
arrays differ from ES5 arrays in that their 'length' property
appears to be a non-configurable accessor property. Clearly,
that better reflects the way Array's 'length' works anyway.
Alternatively, if there's some problem with that, I propose
that array 'length' appears to be a configurable data
property that arrays nevertheless refuse to delete. Either
way, proxies would then be able to emulate them faithfully.
This is also my feeling: part of the awkwardness in emulating
array "length" is definitely that we're trying to mimic the
behavior of an accessor property using a mutable data property.
Would Mark's suggestion be too radical a change? (note: I'm not
arguing for this change on the grounds of "it's too awkward to
emulate using proxies". I'm arguing on the grounds of "ES5
accessor properties seem to better describe the behavior of a
dynamic property such as array |length|").
In arrays, "length" affect numerical properties, but the opposite
is also true. Should all numerical properties be considered as
accessors then? (there is a little bit of bad faith here, because
a valid implementation is possible with just "length" being an
accessor. See [1]).
Considering "length" as a data or accessor property is a secondary
question in my opinion. The "magic" behavior is not at the
property level but at the object level (even though it can be
emulated at the property level).
The question raised by Mark is: "should objects with noticeable
custom internal method (array, host objects, proxies...) be
allowed to prentend having data property even if some logic is
triggered under the hood?".
Almost, and thanks for trying to summarize. My question is
"Should ... be allowed to pretend having a *non-configurable* data
property ...?"
A perfectly fine answer to the array.length issue is to have length be
a configurable data property so long as it needs to operate in a
magical manner. For all such problematic magical behavior, we should
likewise report the property as configurable so long as it needs to
operate in a magical manner.
Currently, the "configurable" attributes has two meanings. At the same
time it tells who whether or not you can delete the property and whether
or not you can reconfigure (call to Object.defineProperty) your
property. If I understand well, you would like it also to tell whether
the property is magical or not.
If we are at a point where we'd break Object.defineProperty return
values, shouldn't we add new keywords rather than adding semantics to
current attribute keywords?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
