- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 05 Jan 2012 12:10:30 +1100
- To: João Eiras <joaoe@opera.com>
- CC: public-script-coord@w3.org
João Eiras:
> I seriously suggest that objects with a length and numbered properties
> (like "{length:1,0:1}") be supported though. The only practical
> difference with Array is that the object does not inherit the Array
> prototype, and hence does not support its methods, but that is not
> necessary for the host's function implementation.
>
> ecmascript is flexible enough to allow other object types to be used as
> arrays
> var x = {};
> [].push.call(x, 1);
> [].push.call(x, 2);
> // x == {length: 2, 0: 1, 1: 2}
>
> jQuery objects are not arrays, yet they have length and numbered
> properties.
This used to be allowed, for the reasons you state. I mentioned in
http://www.w3.org/mid/4EEFE632.9010506@mcc.id.au that disallowing it
allows overloading on sequences and dictionaries, and was generally
helpful in simplifying the overload resolution algorithm.
> Anyone could have their own custom object types which set these
> properties. And if some host function needs an array, then if the native
> object has all the data needed there would be no need for the author to
> recreate the object.
Sure. You might even think that if there is no overloading present that
you should be allowed to treat {length:2,...} as a sequence, since
there's no ambiguity, but I thought it was important to ensure that
overloading behaviour doesn't change when new overloads are introduced
later.
> The specification already mentions "platform object that supports
> indexed properties", the same could be allowed for native objects, but
> then functions and Strings would need a special case.
Platform objects are different because they cannot be used as values of
dictionaries and other types where native (user) objects can be used.
Received on Thursday, 5 January 2012 01:11:01 UTC