W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

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

From: João Eiras <joaoe@opera.com>
Date: Fri, 06 Jan 2012 13:40:42 +0100
To: public-script-coord@w3.org
Message-ID: <op.v7nxh4c22q99of@joaoe>
On Thu, 05 Jan 2012 05:35:58 +0100, Cameron McCormack <cam@mcc.id.au>  

> João Eiras:
>> Is it really an issue ? Are there overloaded APIs which support both
>> dictionaries and arrays/sequences ? I don't recall any at the moment. Or
>> if there was ambiguity, renaming one of the overloads would be an  
>> option.
> Currently there are not, but I thought Anne's request to allow this kind  
> of overloading (for the DOM method proposal of having an append() take  
> various kinds of values) was reasonable.

I would consider an API which is overloaded with a dictionary and an array  
a really poorly designed API, or any API with overloads even (disregarding  
variable number of arguments) and think it should not be encouraged.  
Instead if the parameter types can be confused (which happens easily in  
languages with weak typing) either by reading code, or by using types  
which at runtime are similar, different method names should be preferred.

It is simpler to specify and understand the behavior for  
"appendList(array)" and "appendDict(dictionary)" than "append(array)" and  

> I think the kind of API where you can pass a single item or an array of  
> items is not uncommon.  And allowing primitive types and DOMString as  
> the item type but not dictionary types seems a bit limiting.

I did not suggest that and share your opinion on this issue.

> In the future it will be possible to create an object that has [[Class]]  
> == "Array" (maybe via the proposed <| operator), and jQuery results  
> objects could be real arrays, be allowed as sequence values, and still  
> have custom prototypes to hold all of the jQuery methods.

That would be a really nice thing, but if there isn't a solution the whole  
overloading feature is less flexible.
Received on Friday, 6 January 2012 12:43:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC