On Thu, Jun 16, 2011 at 7:24 PM, Cameron McCormack <[email protected]> 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. > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
