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

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

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Thu, 21 Jul 2011 13:51:49 -0700
Cc: public-script-coord@w3.org
Message-Id: <0D97B625-3D88-428F-9506-BD2AB9C6FA71@wirfs-brock.com>
To: Jonas Sicking <jonas@sicking.cc>

On Jul 21, 2011, at 12:22 PM, Jonas Sicking wrote:

> Consider the following WebIDL:
> dictionary FooOptions {
> boolean reverse = false;
> unsigned long limit;
> };
> interface Foo {
>  void someFunc(in DOMString name, optional in FooOptions options);
> };
> This creates an API that is intended to be called like:
> myfoo.someFunc("name", { reverse: true });
> however, as currently defined, you can call it with:
> 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,

Actually, the object that is the result of the conversion does have properties...all of the properties defined by Number.prototype and Object.prototype.

> all properties in the dictionary will get
> their default value.

not if the dictionary definition included  members with names like "constructor", "toFixed", "valueOf", isPrototypeOf", etc.

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

sounds reasonable

> This does leave the question what to do for something like:
> myfoo.someFunc("name", null);
> and
> myfoo.someFunc("name", undefined);

as currently specified, the ToObject mentioned above will throw for those values.
> 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);
> }
Or somebody might reasonably right a "getOptions" routine that either results an object or undefined indicating to use defaults (checking for undefined as a result is easier and cheaper than checking for an object that has no properties). So, they might write:


and it would be for undefined to be treated meaning use default values.

Received on Thursday, 21 July 2011 20:52:23 UTC

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