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? -BorisReceived on Thursday, 11 October 2012 02:04:19 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:07 UTC