Re: [WebIDL] Indexed properties and [[Extensible]]

David Flanagan:
> §4.5.2 indicates that indexed properties won't be added to an object
> if its [[Extensible]] attribute is false.  I take this to mean that
> conforming objects will work like regular JavaScript objects for
> Object.preventExtensions() as well as Object.seal() and
> Object.freeze().  Is this the intent?

Yes that was the intent.

> Let's take NodeList as a concrete example, keeping in mind that DOM
> Core requires that the childNodes property of a Node always returns
> the same NodeList object and that that object is live:
> 
> var div = document.createElement("div");
> div.appendChild(document.createTextNode("test"));
> var kids = div.childNodes;  // a NodeList
> kids.freeze()                       // This should work, right?
> // I think this should succeed despite the freeze() above, right?
> div.appendChild(document.createTextNode("foo"));
> div.childNodes[0]               // => the original text node "test"
> div.childNodes[1]               // => undefined because of freeze
> div.childNodes.length;       // But this is 2, right?
> div.childNodes.item(1);      // What does this return?
> 
> This seems like a nasty can of worms to me.  A simpler approach
> would be to require an implementation to throw a TypeError on any
> attempt to set [[Extensible]] to false on an object that has an
> indexed getter.  It just doesn't make sense to be able to freeze a
> live collection.

I think that’s a fine idea; let’s do that.

> (Does WebIDL need to make a distinction between interfaces that are
> live and those that are not?  Should there be a [Freezeable]
> attribute for non-live interfaces with indexed getters?)

We could do that.  It might be easier just to disallow freezing of all
objects that support indexed/named properties, though.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 26 May 2011 00:06:23 UTC