Re: IndexedDB: undefined parameters

Boris Zbarsky wrote:
> In fact, WebIDL doesn't even do what you want here with 
> [TreatUndefinedAs=Missing].  All that does is that if it's present on 
> an argument and all arguments after it, and if all the values passed 
> for all those arguments are undefined, then the effective overload 
> used is the one with all those arguments omitted.  So if you have this 
> IDL:
>
>   void foo([TreatUndefinedAs=Missing] optional int foo,
>            [TreatUndefinedAs=Missing] optional int bar);
>
> and you make this call:
>
>   foo(undefined, 5)
>
> this will behave the same as foo(0, 5).
>
> Basically, TreatUndefinedAs=Missing is meant to let you pretend like 
> trailing undefined values don't affect arguments.length, in ES terms.

This is all consistent with draft ES6, per Ecma TC39 and its Editor, @awbjs.

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

undefined is the one value that acts as the default-triggering sentinel, 
whether trailing or not. This supports composition by delegation, where 
f(a,b,c) and f calls g(a,b,c) and g has default parameters triggers 
defaulting no matter how many or few actual arguments f receives -- 
without f having to specialize on arguments.length and call g with 0, 1, 
or 2 actuals.

> Think about all this from the point of view of an ES impl of foo() 
> above.  How would you represent, in an ES function that expects its 
> first argument to be an int and the second argument to be an int but 
> makes them optional, the concept of "second int passed, but first not 
> passed"?  However you'd do that, that's probably what WebIDL should 
> aim for.

undefined as first actual, int as second.

> ccing public-script-coord here, because it seems like there's some 
> serious lack of clarity about what WebIDL does now and what behavior 
> people want out of it.

ES6 draft on default parameters is now clear.

/be

Received on Thursday, 11 October 2012 01:55:45 UTC