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

[WebIDL] Dictionaries and undefined

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 10 Oct 2011 22:56:21 -0700
Message-ID: <CA+c2ei826Z5gjC6uN+WCyH36Ewft-nyG5=pW9cYHSqitNi_C1w@mail.gmail.com>
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




rather than


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


myBaz.func({val: undefined});

be equivalent to

myBaz.func({val: "candy"});


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC