Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On Mon, Aug 8, 2011 at 3:14 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Cameron McCormack:
>>>
>>> If there are just one or two exceptions, and people are happy with the
>>> general approach of "undefined means the same as missing (optional?)
>>> argument", then we could do just that.
>
> Jonas Sicking:
>>
>> I'm certainly happy with it.
>
> I'll investigate existing APIs to see how many we would need to annotate
> with "explicit undefined doesn't mean missing argument" behaviour.
>
>> I do think we should lump DOMString with other primitives. In fact,
>> I'd prefer to simply say "string" in the IDL.
>
> There was some desire to change "DOMString" to "string" in the past, but I
> thought it was you who objected, due to "string" meaning something different
> in our XPIDL stuff.  If there actually are no objections, then I would
> prefer to make that change too. :-)
>
> I will take a more thorough look at existing IDL to see whether DOMString vs
> primitive type overloading is necessary at the moment.

Acutally, I was arguing back then too that the fact that this collides
with our XPIDL doesn't matter since we can't use WebIDL in our code
directly anyway for a host of other reasons.

>> I do definitely agree that we don't want to complicate the overload
>> resolution algorithm though. In particular in a way that would cause
>> slower performance. But don't you have to deal with this anyway if
>> there are two functions like
>>
>> void f(in unsigned long x);
>> void f(in boolean x);
>
> That is already disallowed in IDL, since they're both primitive types. The
> table at http://dev.w3.org/2006/webapi/WebIDL/#dfn-distinguishable shows
> which types can be used to distinguish overloads.

That seems unfortunate. Though if the need arises we can always add
support for it later.

>>> Currently, operations with optional arguments are purely sugar for
>>> overloads
>>> with the different variations of missing arguments, e.g.
>>>
>>>  void f(in optional DOMString x);
>>>  void f(in object y);
>>>
>>> is exactly the same as
>>>
>>>  void f();
>>>  void f(in DOMString x);
>>>  void f(in object y);
>>>
>>> so if possible, I would like to avoid ascribing different behaviour to
>>> the
>>> two.  I think it could be confusing, especially if the difference is only
>>> in
>>> this kind of edge case of passing undefined.
>>
>> 100% Agreed!
>>
>> I guess that would mean that we'd have to say that 'undefined' also
>> has special meaning if there are overloads that take fewer arguments
>> too. In addition to saying that it has special meaning if there are
>> overloads which take optional arguments.
>>
>> Which complicates the overload algorithm. Which is a bummer :(
>>
>> It still seems to me that it's the better thing to do though.
>
> Sorry, I got a bit confused with the above.  Are you saying that you think
> it's better to complicate the overload algorithm in this case to make
> explicit undefined passed to an operation with an optional argument mean the
> same thing as leaving it out, but for actual overloads for it to mean a
> value was indeed passed (and to cause it to match any primitive type plus
> DOMString)?

I'm saying that I think the following two interfaces should be exactly
equivalent:

interface i {
  void f(in optional DOMString x);
  void f(in object y);
};

interface i {
  void f();
  void f(in DOMString x);
  void f(in object y);
};

and in both cases the following two should be equivalent:

x.f(undefined);
x.f();

and neither should be equivalent to

x.f("undefined");

I'm also saying that I'm aware that this will complicate the overload
algorithm, but I think that's worth it. Especially since it shouldn't
result in worse runtime performance.

/ Jonas

Received on Monday, 8 August 2011 22:26:04 UTC