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

On Mon, Aug 22, 2011 at 4:23 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> On 22/07/11 7:22 AM, Jonas Sicking wrote:
>>
>> dictionary FooOptions {
>>  boolean reverse = false;
>>  unsigned long limit;
>> };
>>
>> interface Foo {
>>   void someFunc(in DOMString name, optional in FooOptions options);
>> };
>
> ...
>>
>> myfoo.someFunc("name", 4);
>>
>> The dictionary algorithm will convert the '4' to an object and then
>> attempt to read properties off that object. However since the object
>> won't have any properties, all properties in the dictionary will get
>> their default value. In other words, the above is equivalent to
>>
>> myfoo.someFunc("name", {});
>> and
>> myfoo.someFunc("name");
>>
>> It seems to very likely that if someone passes in a non-object, they
>> have a bug in their code and we would do them a bigger service by
>> throwing an exception than silently ignoring their argument.
>
> I agree.
>
>> This does leave the question what to do for something like:
>>
>> myfoo.someFunc("name", null);
>> and
>> myfoo.someFunc("name", undefined);
>>
>> It seems useful to me to allow both these and use the default values
>> in both cases. For example for code that looks like:
>>
>> function myDoStuffFunc(name, options) {
>>   getFooObj().someFunc(name, options);
>> }
>
> 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.

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.

> 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 "?".

/ Jonas

Received on Tuesday, 23 August 2011 02:19:18 UTC