- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 04 Aug 2011 11:42:22 +0200
- To: Cameron McCormack <cam@mcc.id.au>
- CC: public-script-coord@w3.org, jonas@sicking.cc, bzbarsky@mit.edu, allen@wirfs-brock.com
On 2011-08-04 02:50, Cameron McCormack wrote:
> On 20/07/11 1:04 AM, Lachlan Hunt wrote:
>> Refer to discussion in a Mozilla bug 648722 [1].
>>
>> When undefined in passed to an overloaded function, the overload
>> resolution algorithm should not exclude nullable non-primitive types.
>
> Thanks for all the discussion in the thread. It sounds like the
> following is what was settled on:
>
> * When undefined is passed, it is always treated the same as if it was
> not passed at all.
No, this is not always true for all methods. Consider:
document.write() // writes nothing
document.write(undefined) // writes "undefined"
Although this particular case isn't overloaded, so the overload
resolution algorithm won't be run.
> * Anywhere an undefined would help select a nullable primitive type
> during overload resolution, it should help select nullable types
> regardless of the inner type. (This would still matter in cases
> where explicit undefined is passed in the middle of the argument list,
> and later arguments are not undefined.)
Is that intended to handle this case?
e.g. consider a function
void f(in DOMString x, in DOMString y, in DOMString z);
f("a", undefined, "c")
This should not throw a type error, even if the function is overloaded.
> And finally for the API at hand:
>
> Element querySelector(in DOMString a, in optional Element b);
> Element querySelector(in DOMString a, in sequence<Node>? b);
>
> Overloads are:
> (DOMString)
> (DOMString, Element)
> (DOMString, sequence<Node>?)
>
> querySelector(undefined) === throw TypeError
No, I don't think that one should throw a type error. Right now, it
stringifies to "undefined" in implementations and doesn't throw.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Thursday, 4 August 2011 09:42:58 UTC