Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On 9/08/11 10:24 AM, Jonas Sicking wrote:
> 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.

Ah. :)  Maybe I was misremembering and it was the WebKit people.

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

Thanks for the clarification.  I agree with the above, but I don't think 
this would complicate the overload resolution algorithm too much (I 
guess that's where I got confused).  Certainly not as much as treating 
operations with optional arguments differently from overloaded 
operations, anyway.

I think the only complication that comes in is when considering "any". 
It would be treated just like window.alert() etc. in that explicit 
undefined is considered a real argument that was passed.  Do you think 
it would be common enough for operations that take any to want to treat 
undefined as a real value, rather than an omitted argument?  If not, 
then we could treat it the same way as window.alert(), if we are happy 
for that mechanism not to be labelled a "for legacy use only" thing.

Received on Monday, 8 August 2011 22:54:11 UTC