Array-like interfaces defined using indexed property setters, creators and/or deleters don't behave nicely. They can't be used in conjunction with Array.prototype functions unless we require the interface to support sparse array indexes. They also don't seem to be used (there are plenty of indexed property getters on the other hand).
There is at least this use of an indexed property deleter:
but that is pretty weird and bad design anyway IMO.
If we can remove indexed property setters, creators and deleters then we can think about a solution for mutable array-like objects that work better with JS Arrays.
See also https://mail.mozilla.org/pipermail/es-discuss/2012-December/027688.html for problems with [ArrayClass], which is related.
HTMLOptionsCollection has an indexed setter/creator, and that's required for web compat. I agree it's weird and bad design and generally crappy, but we can't get rid of it...
I'm not sure offhand whether anything needs deleters for backwards compat, but I doubt it.
I missed HTMLOptionsCollection as it is not using the terms from IDL.
Which terms, out of curiosity?
"indexed property setters" and friends.
For what it's worth, HTMLSelectElement also has an indexed setter/creator, also required for web compat. I missed it in my scan last night because we haven't converted it to WebIDL yet.
(In reply to comment #2)
> HTMLOptionsCollection has an indexed setter/creator, and that's required for
> web compat. I agree it's weird and bad design and generally crappy, but we
> can't get rid of it...
> I'm not sure offhand whether anything needs deleters for backwards compat,
> but I doubt it.
We can't get rid of what's needed for compat, but if we agree that they're bad design (which seems to be the case) we can rename them legacy* to flag the fact that they shouldn't be used for new APIs.
Filed bug 20570 and bug 20571 on HTML.
I removed indexed property deleters:
Leaving this open for potentially renaming the rest to legacy*.