Re: Reconciling handling of optional arguments and handling of default values across ES and webidl

On 5/8/13 6:25 PM, Jonas Sicking wrote:
>> 2)  Have arguments.length not include trailing undefined values.
>
> This I'm not so sure about. While I think that treating undefined as
> "use default behavior", aka "not passed" is likely the right behavior
> in almost every case, it seems scary to completely disable the ability
> for the callee to tell if undefined was explicitly passed or not.

OK.

If we keep this, then in WebIDL we also need to keep the ability to 
distinguish between different function behaviors (let's call them 
"overloads" and hope Allen forgives us) by explicitly passing undefined 
for trailing arguments.

That introduces unfortunate complexity, because now we need to have a 
way, for these trailing arguments, to differentiate "not passed" and 
"undefined explicitly passed"...

> I.e. this removes the ability for a function to accept any value, while
> also having a different behavior for "nothing was passed".

So the question is, what are the use cases for having different behavior 
for "undefined was passed" and "nothing was passed".

I'll assume there are legacy APIs which depend on the difference; which 
ones?  Optional arguments are rare in DOM APIs until recently, and I 
hope no one has created a DOM API recently that makes such a 
distinction, so is this just a matter of some backwards-compat ES spec 
algorithms?  If so, can we get away with not allowing such behavior in 
web APIs at all?  That would mean that some of the ES spec's builtins 
can't be expressed in WebIDL, but that's a non-goal anyway.

> Being able to inspect arguments.length has always seemed like a nice
> escape valve to satisfy the odd use case where people wanted to make
> the distinction.

What _are_ the use cases?

> I take it that you are also proposing that
>
> 3) rest parameters wouldn't pick up any trailing undefined values.

Hmm.  This one is tough.  I guess it makes sense for rest parameters to 
pick up trailing undefined.  For that matter if we ever start allowing 
"rest" parameters in the middle of function signatures (which I think 
might be nice, in fact, at least for IDL), we'd want them to pick up any 
sequence of arguments, undefined or not, in between the non-rest 
arguments....

-Boris

Received on Thursday, 9 May 2013 00:56:47 UTC