Re: IndexedDB: undefined parameters

On Thu, Oct 11, 2012 at 9:36 AM, Allen Wirfs-Brock
<allen@wirfs-brock.com> wrote:
>
> On Oct 10, 2012, at 10:57 PM, Jonas Sicking wrote:
>
>> On Wed, Oct 10, 2012 at 7:15 PM, Brendan Eich <brendan@mozilla.org> wrote:
>>> Boris Zbarsky wrote:
>>>>
>>>> Should "undefined", when provided for a dictionary entry, also be treated
>>>> as "not present"?  That is, should passing a dictionary like so:
>>>>
>>>>  { a: undefined }
>>>>
>>>> be equivalent to passing a dictionary that does not contain "a" at all?
>>>
>>> ES6 says no. That's a bridge too far. Parameter lists are not objects!
>>
>> I thought the idea was that for something like:
>>
>> function f({ a = 42 }) {
>>  console.log(a);
>> }
>> obj = {};
>> f({ a: obj.prop });
> According to the ES6 spec. this evaluates to exactly the same call as:
>
> f({a: undefined});
>
> According to ES6 all of the following will log 42:
>
> f({});
> f({a: undefined});
> f({a: obj.prop});
>
>>
>> that that would log 42.
>>
>> What is the reason for making this different from:
>>
>> function f(a = 42) {
>>  console.log(a);
>> }
>> obj = {};
>> f(obj.prop);
>
> same as:
>  f(undefined);
> and
>  f();
>
> Again, all log 42 according to the ES6 rules.

Great!

> Finally, note that in EsS6 there is a way to distinguish between  an absent parameter and an explicitly passed undefined and still destructure an arguments object:
>
> function f(arg1) {
>    if (arguments.length < 1) return f_0arg_overload();
>    var [{a = 42} = {a: 42} ] = arguments;  //if arg1 is undefined destructure  {a:42} else destructure arg1using a default value for property "a"
>    ...
> }

Yup. Behavior like this can always be specified using prose, so we're
not closing any options.

>> It seems to me that the same "it'll do the right thing in all
>> practical contexts" argument applied equally to both cases?
>
> It really seems contra-productive for WebIDL to try to have defaulting rules for "option objects" that are different from the ES6 destructuring rules for such objects.

Agreed.

So I recommend we make the following change to WebIDL:

Always treat passed 'undefined' values the same as not passing the
argument with regards to when to pick up the default value as well as
when to consider the argument as specified.

Make the overload resolution treat a passed 'undefined' value the same
as not passing the argument.

Remove [TreatUndefinedAs=Missing].

Make dictionaries treat a passed undefined value the same as not
passing the value. I.e. it would pick up any defaults if they are
defined and it would flag the value as not specified otherwise.

Allow mixing optional arguments with default values and optional
arguments without default values at will. I.e. foo(optional int a,
optional int b=42) should be valid WebIDL.

/ Jonas

Received on Thursday, 11 October 2012 19:07:13 UTC