- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 23 Aug 2011 14:39:45 +1200
- To: Jonas Sicking <jonas@sicking.cc>
- CC: public-script-coord@w3.org
Cameron McCormack:
>> At the moment, you could write
>>
>> interface Foo {
>> void someFunc(DOMString name, optional FooOptions? options);
>> };
>>
>> so that null is a valid value of the second argument, and you write prose
>> handling that case. There's slight utility in allowing null (or undefined)
>> versus { } -- for the cases that Allen brings up where the dictionaries have
>> members whose names are the names of properties from Object.prototype.
Jonas Sicking:
> Is there? I can't think of any sane situation when a page would want
> to add something to Object.prototype and then pass {}, null or
> undefined as a dictionary parameter as a way to specify arguments to a
> function.
>
> I certainly agree that it should work, but I don't think it'll be
> common enough that we should adjust any API or syntax to it.
No, it wouldn't be for sane situations, you're right.
>> So I would be OK with changing the rules in #es-dictionary so that null and
>> undefined get converted into empty dictionaries. The trouble though is when
>> considering overloading -- I am not sure that I would want null or undefined
>> to select an operation whose argument type is a dictionary.
>
> I don't think we should do this. We should use the same rules as for
> all other parameters instead. So undefined would throw unless the
> argument is optional, and null would throw unless the type is followed
> by a "?".
Cool, that's simpler then and with the resolution of the "undefined as
optional argument" issue, this doesn't need any spec change.
Received on Tuesday, 23 August 2011 02:40:27 UTC