On 10/10/12 9:55 PM, Brendan Eich wrote:
undefined is the one value that acts as the default-triggering sentinel,
...
Think about all this from the point of view of an ES impl of foo()
above. How would you represent, in an ES function that expects its
first argument to be an int and the second argument to be an int but
makes them optional, the concept of "second int passed, but first not
passed"? However you'd do that, that's probably what WebIDL should
aim for.
undefined as first actual, int as second.
OK, so it sounds like there are two proposals for changes to WebIDL here:
1) If undefined is passed for an optional value that has a default
value, the default value should be used.
2) If undefined is passed for an optional value that does NOT have a
default value, the value should be considered as "not present" (similar
to the equivalent concept for dictionaries).
Should "undefined", when provided for a dictionary entry, also be
treated as "not present"? That is, should passing a dictionary like so:
{ a: undefined }
be equivalent to passing a dictionary that does not contain "a" at all?
How should #2 above interact with the overload resolution algorithm? Or
does it not affect it at all?
-Boris
