Re: Omissions in IDL sequence and IDL array conversion to ES array

On Wed, 04 Jan 2012 03:10:00 +0100, Cameron McCormack <cam@mcc.id.au>  
wrote:

> João Eiras:
>>> I have some questions about the following two sections
>>> * http://dev.w3.org/2006/webapi/WebIDL/#es-sequence
>>> * http://dev.w3.org/2006/webapi/WebIDL/#es-array
>>>
>>> For the sake of the examples, exampleFunction is a function which
>>> converts the first argument to an ES Array.
>
> James Graham:
>> My reading of the specification is that your examples would throw
>> TypeError because given an operation like
>>
>> void foo(array);
>>
>> the overload resolution algorithm will return no matches unless the
>> passed type is "is a platform array object, a native Array object, or a
>> platform object that supports indexed properties", which I think your
>> examples are not.
>
> That's correct.
>
> When assigning to IDL attributes, however, we don't run the overload  
> resolution algorithm that would weed out certain kinds of values.  That  
> means that assigning to an attribute of type T[] would accept some  
> values that calling an operation with an argument of type T[] wouldn't.  
>   That doesn't seem useful, so I will try to ensure that all of the  
> "convert ES to IDL value" algorithms accept only the kinds of values  
> that you could get out of the overload resolution algorithm anyway.
>
>

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.

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.

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.

Received on Wednesday, 4 January 2012 15:48:16 UTC