Array Like Interface
Allen.Wirfs-Brock at microsoft.com
Mon May 18 10:27:54 PDT 2009
>From: Garrett Smith [mailto:dhtmlkitchen at gmail.com]
>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.
>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.
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