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
