Array Like Interface
Allen.Wirfs-Brock at microsoft.com
Fri May 15 10:34:46 PDT 2009
The ES specification implicitly defines such an interface. It is essentially, the union of the requirements that an object must support if it is going to work correctly with the specified generic array methods. Those implicit requirements are fairly basic, but include the standard specified behavior of internal methods such as [[Put]] (without that assumption, the specified algorithms are meaningless).
There is nothing stopping HTML or WebIDL from specify an interface that fully conforms to this implicit "generic array" interface.
Note that the host object exceptions in the Es5 spec. permits, but do not require that hosts take liberties with the ES specified object semantics. In particular, there is no reason that a browser cannot implement DOM objects as "native objects" rather than "host objects". Nor, from an ES specification perspective, there is no particular reason that the ES binding of WebIDL should permit use of host object semantics (which pretty means unspecified) rather than native object semantics. However, those responsible for maintaining and incrementally evolving existing implementations probably would have a different take on this matter.
I'm not saying that there is no value in being more explicit about the actual requirements for an object to be a fully functional generic array-like object. However, for objects that conform to the requirements of "native objects" there no ambiguity about the implicit requirements. To me it seems that the issue is really more about whether you want to continue to allow the semantics of some or all DOM objects to arbitrarily deviate from the semantics of native ECMAScript objects.
More information about the es-discuss