Array Like Interface

Garrett Smith dhtmlkitchen at gmail.com
Fri May 15 18:05:03 PDT 2009


On Fri, May 15, 2009 at 10:34 AM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com> wrote:
> 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).
>

Right. The problem is that that implied interface is not fulfilled in
a compatible way IE. IE has list-like host objects which do not work
with Array generics, even though those objects appear to support
[[Get]] and length. However, in some cases, IE will err with even a
simple [[Get]] property access operation. The pragmatic advice that is
concluded after making such observations is that same c.l.js mantra:
"Don't trust host objects."

By having an explicit interface, instead of an implicit one, the hope
is that browsers would see that and make their host objects have an
interface that is predictably compatible.

> There is nothing stopping HTML or WebIDL from specify an interface that fully conforms to this implicit "generic array" interface.

The Web IDL has IndexGetter and IndexSetter -- not quite interfaces,
in a formal sense. The Web IDL calls these [[IndexGetter]] and
[[IndexSetter]] -- not quite interfaces, in a formal sense. A type of
object that has an index setter would also seem to need an index
getter, and either would need a length, so two interfaces would seem
to suffice.

Such interface(s) would be something of a tagging interface for a
feature check that scripts for pages could use, which could encourage
and would likely give rise to scripts performing stronger inferencial
checks, instead of unrelatated inferences, such as the classic user
agent sniff.

>
> 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.
>

Host objects currently behave in implementation-dependent manner.
Nobody likes it, but that's the way it is. I do not think such
"implementation dependent" behavior should be arbitrary. I would very
much like to have a way to determine the outcome of calling
Array.prototype.slice.call( hostObject ); That would ensure that
scripts can be backwards and forwards compatible without version
checks, opt-in versioning, or unrelated inferences.

> Allen
>
>
>


More information about the es-discuss mailing list