[Harmony Proxies] Proposal: Property fixing
Mark S. Miller
erights at google.com
Thu Jun 16 09:15:57 PDT 2011
On Thu, Jun 16, 2011 at 9:09 AM, David Bruant <david.bruant at labri.fr> wrote:
> Le 16/06/2011 17:46, Mark S. Miller a écrit :
> On Thu, Jun 16, 2011 at 8:29 AM, David Bruant <david.bruant at labri.fr>wrote:
>> Le 16/06/2011 16:50, Tom Van Cutsem a écrit :
>> 2011/6/16 Mark S. Miller <erights at google.com>
>>> 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 ).
>> 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
>> 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
> 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?
I do not believe so. The host object contract for configurable shows that
the only meaning it ever had in ES5 that one could count on is "this is not
guaranteed not to be magical". The proxy spec already allows the same
violations of the first two meanings you suggest:
* a proxy and a compliant ES5 host object may refuse to delete a
configurable property, and
* a proxy and a compliant ES5 host object may refuse an attempt to
reconfigure a configurable property.
In summary, "configurable" was never a guarantee of anything.
"non-configurable" was the only state that came with guarantees. Let's not
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss