[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

Oliver Hunt oliver at apple.com
Mon Aug 2 12:47:13 PDT 2010


On Aug 2, 2010, at 12:25 PM, Garrett Smith wrote:

> On 8/2/10, Oliver Hunt <oliver at apple.com> wrote:
>> 
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>> 
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>>> all array functions defined in ES5 are "generic" in that they work
>>>> over any array-like object.
>>> 
>>> They're guaranteed to work over any array-like native JavaScript object.
>>> They're *not* guaranteed to work on host objects like the various node
>>> lists.
>> 
>> Uhhh, I have no idea what you're talking about -- there are no type checks
>> in any of the array prototype functions, they all operate in terms of
>> property access alone, all the methods we're talking about basically start
>> out like this:
>> 
> 
> [..]
> 
> And they continue like this:
> 
> "Whether the [something] function can be applied successfully to a
> host object is implementation-dependent."
> 
> Where "[something]" is replaced by "slice" in this case.
> 
>> Eg. "array-like" in the context of ES5 should be interpreted as "has a
>> property named 'length', the array methods will work on any type.
>> 
> 
> That is not true. ECMAScript has what is called "host object". A host
> is any ecmascript object that is not defined by the specification; it
> is not a user-defined object (because that explicitly defined to be a
> native object).
> 
> A host object may or may not be implemented as a native ECMAScript
> object. That leaves two types of host objects:
> 1) native
> 2) non-native
> 
> More on that:
> <https://mail.mozilla.org/pipermail/es-discuss/2010-July/thread.html#11501>
> 
> Nothing says that any of the various dom "collection" objects must be
> native object.
> 
> The W3C does not define an interface "collection"; The term itself
> comes from Microsoft IE 4, which predates the w3c DOM; hence the
> quotes around the term "collection".

I didn't say that Host Objects don't exist, i said that "array like" is equivalent basically "has a property named length"

Things like Array.prototype.splice not working "as expected" on a NodeList is because the numeric properties on the nodelist are essentially DontDelete(or configurable=false in es5)

If I define an Object with:
var o = {length:1};
Object.defineProperty(o, "0", {value: "foo", configurable: false});

Then do:
var result = Array.prototype.splice.call(o, 0)

result will be ["foo"], but the property will not have been removed from object o.

There is no part of the spec that performs a type check, being a Host Object does not get you out of the required behaviour of the Array methods.

The reason the behaviour of Host Objects is considered magic is not so that you can say a function doesn't need to work on them, it is _specifically_ to allow the behaviour shown by the DOM where you can have properties that are have the attributes writable=false, configurable=false, and yet can still change.  This is the basis of the Host Object exception.  No property on a non-Host Object can change if it is not writable, yet the DOM requires that there be objects that do just that.

That said there is also no way in which you can implement any of the live collection types using EcmaScript.

Re: IE + Array methods, for whatever reason the ES5 spec does have an addendum that allows an implementation to disallow array methods on host objects -- i think this was foolish as the specification of the array methods should behave exactly as they would with a object with equivalent properties and attributes.

--Oliver




More information about the whatwg mailing list