Re: IndexedDB: undefined parameters

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.


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

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

Allen

Received on Thursday, 11 October 2012 16:36:54 UTC