On Thu, Jun 16, 2011 at 8:13 PM, Mark S. Miller <[email protected]> wrote:
> > > 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. > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
