W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] Converting non-objects to Dictionaries.

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 23 Aug 2011 14:39:45 +1200
Message-ID: <4E5312F1.60504@mcc.id.au>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC