Re: [WebIDL] Treatment of getters and setters
Cameron McCormack wrote: Hello WGs. I’ve just committed changes to Web IDL on how it treats index and name getters and setters. Browers don’t agree on some specifics of how the index and name properties on HTMLCollections are handled, so I’ve tried to make some sensible decisions in these cases. Comments welcome! Here’s a summary of changes to Web IDL: * Removed [IndexGetter], [IndexSetter], [NamedGetter] and [NamedSetter]. * Removed the custom [[Get]] behaviour on host objects. * Added [NumberedIndex] and [NamedIndex], which can appear on interfaces. Both of these can take identifier arguments Creatable, Modifiable and/or Deletable, which control how the properties that are placed on host objects can be interacted with. Properties for [NumberedIndex] are enumerable, and those for [NamedIndex] aren’t. * Changed the custom [[Put]] behaviour on host objects so that it only is there to support [PutForwards]. For details see: http://dev.w3.org/2006/webapi/WebIDL/#NamedIndex http://dev.w3.org/2006/webapi/WebIDL/#NumberedIndex http://dev.w3.org/2006/webapi/WebIDL/#index-properties It seems very unfortunate that we now have to use prose to describe which functions the getters/setters map to. Why was that part of these changes needed? / Jonas
Re: [WebIDL] Treatment of getters and setters
Hi Jonas.
Jonas Sicking:
It seems very unfortunate that we now have to use prose to describe
which functions the getters/setters map to. Why was that part of these
changes needed?
Basically because these are no longer handled by being returned by a
custom [[Get]] method on host objects, and now are described as causing
properties to be created/modified/deleted on the host object. My
reasoning was that if Web IDL depended on an operation returning null to
indicate that there’s no such element in the collection, it breaks the
encapsulation between Web IDL and the spec using it, somewhat.
*thinks a bit*
So, we probably need to keep requiring the spec using [NamedIndex] to
specify in prose what the keys are. That should be sufficient to
nominate operations to be the property creator/modifier/deleter
handlers. For example, something like:
[NumberedIndex, NamedIndex]
interface A {
[NumberedIndexGetter] Element item(in unsigned long index);
[NamedIndexGetter] Element namedItem(in DOMString name);
};
The numbered index has keys in the range 0 ≤ index length.
The named index has a key for every string that when passed to
namedItem() would return a node.
Then the operations could still handle that common case of being the
setter/getter methods.
How does that sound?
--
Cameron McCormack ≝ http://mcc.id.au/
[XHR2] abort event when calling abort()
Currently the spec says to fire an 'abort' event every time abort() is called, no matter what the current state is. This means that if you call abort() back to back five times you'll get five abort events. This does match what Firefox does, however it seems to go against both logic and the ProgressEvent spec. Is there a reason to not just fire the abort event when we are in fact aborting a network transfer? Same thing applies partially to the abort event fired on the upload object. / Jonas
