Re: IndexedDB: undefined parameters

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