On Oct 10, 2012, at 10:57 PM, Jonas Sicking wrote:
> On Wed, Oct 10, 2012 at 7:15 PM, Brendan Eich <bren...@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
