W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 8 May 2013 16:56:52 -0700
Message-ID: <CABZUbM3_LzaSCR6+aX_MUHA-rkd4mD_6t-O53HbtsU67fF-0dg@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 5/8/13, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
>
> On May 8, 2013, at 11:18 AM, Boris Zbarsky wrote:
>
>> This keeps coming up, so here comes a proposal....  I believe what I'm
>> proposing does not represent the status quo for either ES6 or WebIDL, but
>> it seems like the sanest available behavior to me, and I'd like to see
>> what the objections are to it.  I am aware that there has been a good bit
>> of discussion about this in ES6, and I've read all of it that I could
>> find, for what it's worth.  And I think that people are undecided about
>> how exactly "optional" arguments and "default values" should work, which
>> is leading to some wackiness.
>>
>> WebIDL behavior:
>>
>> 1)  Allow any argument to be marked as optional in WebIDL, even if
>> followed by non-optional ones.
>>
>> 2)  Allow any argument that is optional to have a default value provided
>> in WebIDL, even if followed or preceded by optional arguments without
>> default values.
>>
>> 3)  Treat undefined passed for an optional argument as "not passed".  If
>> there is a default value, the default value takes effect.
>>
>> ES behavior:
>>
>> 1)  Allow specifying a default value for any function argument, even if
>> followed or preceded by arguments without default values, with the default
>> taking effect if undefined is passed.
>>
>> 2)  Have arguments.length not include trailing undefined values.
>
> This is not how argument.length is currently specified in either ES5 or ES6.
>  Explicitly passed trailing undefines counts into the determination of
> arguments.length.  That's how JS code distinguishes between missing trailing
> arguments and explicitly passed undefined.  I pretty sure that changing this
> would break existing code including existing poly-fiils for some built-ins
> that are specified to distinguish the missing from undefined arguments
> cases.
>
Yeah, it might.

What was proposed seems backwards. Instead of treating 'undefined' as
missing parameter, shouldn't "missing parameter" be treated as
undefined? That way, the algorithm can handle undefined values being
passed in.
-- 
Garrett
Twitter: @xkit
personx.tumblr.com
Received on Wednesday, 8 May 2013 23:57:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC