Array Like Interface

Allen Wirfs-Brock Allen.Wirfs-Brock at
Mon May 18 10:27:54 PDT 2009

>-----Original Message-----
>From: Garrett Smith [mailto:dhtmlkitchen at]
>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."

So, if the problem is limited to IE then you should continue to convey that this is an issue to the Microsoft IE team. This thread is a good start at that.

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

I'm probably repeating myself here, but an new interface is not necessary to make this requirement explicit.  If you want (and can get agreement) for these objects to fully implement ECMAScript native object semantics then that is all you have to say in the WebIDL JavaScript binding specification.

>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
> hostObject ); That would ensure that
>scripts can be backwards and forwards compatible without version
>checks, opt-in versioning, or unrelated inferences.

Again repeating myself, specifying that these objects must support "native" rather than "host" object semantics would accomplish what you desire.  Either specification approach is a change that you are going to have generate consensus around, first in a specification process and ultimately from implementers.


More information about the es-discuss mailing list