Re: [WebIDL] Dictionaries and undefined

On Mon, Oct 10, 2011 at 10:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

Since arguments.length isn't friendly to strict mode, this seems to be a
good assumption for the future at the very least.

Are there any instances of JS libraries using arguments.length do implement
the sort of check one would do for optional DOMString?, or do they reserve
null for present-but-null and undefined for absent?


> 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({});
>

My $0.02: It should be equivalent to this one. Because if you are writing an
object literal to supply the argument, the syntax binds you providing _some_
val. Let's not force people to write imperative code (or n^2 object
literals).


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


In DOMString? what about discriminating null and undefined? ie undefined is
absent, null is present but void.

In DOMString, undefined is absent. I am not sure if null should be "null" or
"" or what though.

Dominic


> / Jonas
>
>