- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 10 Oct 2011 22:56:21 -0700
- To: public-script-coord@w3.org
Hi All, Consider the following IDL: interface Foo { void func(optional DOMString x); } For such an interface we decided that it would be more "javascripty" to treat myFoo.func(undefined) as myFoo.func(); rather than myFoo.func("undefined"); The argument for this was that most JS libraries will look for arguments with the value 'undefined' rather than check arguments.length to see how many optional arguments were specified. Should we do the same thing for dictionaries? Consider the following IDL: dictionary BarDict { DOMString val; }; interface Bar { void func(BarDict options); }; Here it seems that you could make the same argument that myBar.func({val: undefined}); should be equivalent to myBar.func({}); or myBar.func({val: "undefined"}); I.e. this API was implemented in javascript, would it be more likely that the implementation checked if the arg1.val property was undefined, or if |"val" in arg1| returns true or false? The question similarly applies when there are default arguments. For the IDL dictionary BazDict { DOMString val = "candy"; }; interface Baz { func(BazDic options); }; should myBaz.func({val: undefined}); be equivalent to myBaz.func({val: "candy"}); or myBaz.func({val: "undefined"}); or should it be explicitly different from both and somehow "undefine" the default value? And would it have made a difference of 'val' was of type "DOMString?" instead? / Jonas
Received on Tuesday, 11 October 2011 05:57:19 UTC