[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu Jun 16 20:19:03 PDT 2011


On Thu, Jun 16, 2011 at 8:13 PM, Mark S. Miller <erights at google.com> wrote:

>
>
> On Thu, Jun 16, 2011 at 7:24 PM, Cameron McCormack <cam at mcc.id.au> wrote:
>
>> Cameron McCormack:
>> > > Web IDL requires various properties to be non-configurable, but the
>> ones
>> > > we care about here are just the ones that need to exist on objects
>> that
>> > > will have to be implemented using proxies, right?
>>
>> Mark S. Miller:
>> > Yes. And of those, only the ones that need to have magical behavior that
>> > violates the invariants associated with non-configurability. IIUC, this
>> > exempts WebIDL constants, as they never violate those invariants, no
>> matter
>> > how weird their host object. Is this right?
>>
>> That’s right, they really are constant, and they live on objects with no
>> magical behaviour.
>>
>> > > I believe that list is only:
>> > >
>> > >  1. the length own property on array host objects
>> > >  2. each array index own property on an array host object
>> >
>> > By "array host objects", do you mean, for example, NodeList? Is there a
>> > general definition of "array host object"?
>>
>> No, NodeList is a regular IDL interface which has getters/setters
>> defined on it.
>>
>> Array host objects are ones that feel a bit like native Arrays but are
>> under host object control and which are represented by T[] types in IDL.
>> They’re actually pretty much like a shorthand for defining an interface
>> like NodeList, except that they also have the Array prototype object in
>> their prototype chain.
>>
>> (When we met late last year there was a hope to remove them from the
>> spec due to them not being used anyway, but it turned out I was wrong,
>> and they were being used.)
>>
>> The T[] types: http://dev.w3.org/2006/webapi/WebIDL/#idl-array
>>
>> How values of these types are represented using array host objects in
>> ES: http://dev.w3.org/2006/webapi/WebIDL/#es-array
>>
>>
> Why does each array host object have its own toString method rather than
> using one inherited from Array.prototype? ES5 already says that
> Array.prototype.toString is "intentionally generic; it does not require that
> its *this* value be an Array object." So that should work fine.
>

Unfortunately, that same paragraph does go on to say that "Whether the
toString function can be applied successfully to a host object is
implementation-dependent." If this clause actually prevents using
Array.prototype.toString here, which would be a shame, the how about having
array host object inherit a common toString method from the array host
object prototype object?



>
>
>
>> Maybe in the future when real subclassing of Array can be done, we can
>> change the T[] type to do that instead of having completely separate
>> objects.
>>
>> > I expect that "length" on array host objects should be treated however
>> we
>> > treat "length" on regular arrays. Does this seem reasonable?
>>
>> Yes.
>>
>> > Why do array index own properties of array host objects need to be
>> > non-configurable? What would be lost if these were non-configurable but
>> > array host objects could refuse to delete them?
>>
>> Not much, except for author confusion if they see they are configurable
>> but the object refuses to let them be reconfigured.  The alternative,
>> having them be non-configurable, non-writable (for read only arrays)
>> data properties whose value changes also has an element of confusion
>> about them, though.  I think on balance that leaving them be
>> configurable and refusing to reconfigure them is the lesser of the two
>> confusions.
>>
>> I agree with other parts of this thread about having length on Array
>> instances be a non-configurable accessor property – that’s much closer
>> to how I’d expect length properties to be defined if we were doing it
>> from scratch, less magical.  (So in fact we could do that for array host
>> objects; it’s just written the way it is at the moment to mirror the
>> native Array length property.)
>>
>> > > In my upcoming change, [[GetOwnProperty]] will be specified to
>> > > return this property descriptor for property "0":
>> > >
>> > >  { [[Writable]]:false, [[Enumerable]]:true, [[Configurable]]:true,
>> > >    [[Value]]:theHTMLFormElement }
>> > >
>> > > but to refuse to allow the property to be reconfigured.
>> >
>> > Great! So long as this property claims to be configurable, it raises
>> > none of these issues.
>>
>> Excellent.
>>
>> > > It would be nice if the z property could be allowed to be defined and
>> > > exposed as a non-configurable property, but this can’t be done without
>> > > the proxy proposal changes being discussed here.
>> >
>> > I'm curious why you think this would be nice?
>>
>> Because it’s what the author requested.  Presumably they have some
>> reason for wanting to define a non-configurable property.
>>
>> This wouldn’t work for objects with named properties, though, since if z
>> is first exposed as a non-configurable property, and then an item is
>> added to the collection later with the name "z", it will appear to have
>> changed.
>>
>> --
>> Cameron McCormack ≝ http://mcc.id.au/
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>



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


More information about the es-discuss mailing list