[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu Jun 16 08:46:39 PDT 2011


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 [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.

But as pointed out by an earlier message, my original suggestion, that array
length be a non-configurable accessor, is wrong, as it would prevent it from
becoming a non-configurable data property when freezing the array. So, while
it's magical, either configurable data or configurable accessor would work.
Once an array is frozen (or even length by itself frozen), its length no
longer needs to be magical.

In summary, all arrays, Object.defineProperty(array, 'length', {writable:
true, configurable: false}) should always be rejected. Likewise for any
similarly problematic properties we encounter.



> If they are not, then, the notion of "data descriptor" does not make sense
> in the context of proxies because anytime a proxy could trigger any code.
> Should data property descriptor be entirely banned from proxies (and host
> objects)?
>
> There is a cursor to put between data and accessor properties. My opinion
> is that an accessor property should be used when it has a side effect
> *outside the object scope*. For instance, document.cookie should be an
> accessor, because it affects something else than the document object (namely
> other tabs if these send requests to the same domain). Same for
> element.innerHTML which triggers a reflow. However, array.length doesn't
> have any observable effect outside of the object it's being used on.
> I am fully aware that the first flaw of this definition is that there is no
> way to enforce it in a program (especially not in getOwnPropertyDescriptor
> proxy traps return value). However, this separation may be a guideline for
> the spec purpose.
>
> What are your thoughts on this separation?
>
> David
>
> [1]
> http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array/#ecmascript_5_accessors_to_the_rescue
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/95060610/attachment.html>


More information about the es-discuss mailing list