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 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/ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
