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: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 23 Jan 2012 14:12:25 +1100
Message-ID: <4F1CD019.4020202@mcc.id.au>
To: public-script-coord@w3.org
CC: João Eiras <joaoe@opera.com>
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.

Cameron McCormack:
>> 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.

João Eiras:
> 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 "append(dictionary)".

I disagree that it would be a really poorly designed API.  In JS 
libraries, it's quite common to inspect the type of value you get as a 
function argument, and as long as the rules are clear, I think it is 
fine.  Having to use separate functions like appendList and appendDict, 
if not necessary, would make the API less usable IMO.

>> 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.

If we continue to allow any non-Array object to be used for sequence<T> 
etc. then we won't be able to allow overloading dictionaries vs arrays 
in the future.

I'm not convinced that disallowing ({ length: n }) objects like jQuery 
result objects is a big problem.  If anyone else feels like it would be, 
please speak up.
Received on Monday, 23 January 2012 03:12:56 UTC

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