undefined being treated as a missing optional argument

Peter van der Zee ecma at qfox.nl
Fri Apr 13 01:34:04 PDT 2012


Fwiw, arguments.length is currently the _only_ way of properly
detecting the correct number of explicit variables of _any_ type. I
would hate for that behavior to change in the case of explicitly
passing on undefined.

Default values of course do need to be set in the arguments array so
it's length will depend on that. Can we maybe set an extra property on
the arguments array that tells us how many arguments were explicitly
passed on, counting any type? I don't see how we could otherwise
figure that out, especially not after default values clobber this
count.

- peter

On Fri, Apr 13, 2012 at 8:27 AM, Erik Arvidsson
<erik.arvidsson at gmail.com> wrote:
> This is covered on the wiki too.
>
> http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
>
> On Thu, Apr 12, 2012 at 20:38, Russell Leggett
> <russell.leggett at gmail.com> wrote:
>>> The examples cited are arguably cases where the built-in behaviour is
>>> unintuitive to many JavaScript developers, because it doesn't match their
>>> expectation with user code functions and most other built-ins.  I don't view
>>> any of the cases listed as validation that we would *want* that behaviour by
>>> default, just that there are a non-zero number of cases where it exists
>>> today.
>>>
>>> > I suggest that the appropriate way to think of about the current
>>> > behavior, in the context of ES6, is that function f(a) {...} is equivalent
>>> > to function f(a=undefined) {...}
>>> > In other words, there is a default initialization expression, if one is
>>> > not specified. So, f() and f(undefined) appear to produce the same result.
>>>
>>> This is a good way of explaining the proposed semantics, but...
>>>
>>> > But I see why somebody calling a function defined as function(a={
>>> > }){...} explicitly as f(undefined) would expect to trigger the default
>>> >  value initializer.
>>>
>>> Right.  This is exactly the sort of thing I'm worried about, and seems
>>> like the practical common case for default values.
>>>
>>>
>>>
>>> >> 2) The fact that JavaScript (at least for user objects) currently
>>> >> doesn't differentiate between missing arguments and undefined arguments is a
>>> >> nice simplifying rule in the language that is easy to understand..
>>>
>>> > It does differentiate, at least in regard to the arguments object.
>>>
>>> True.  But this is uncommon enough as to not be something most developers
>>> deal with.  Default values aim to be a much more commonly used tool.
>>>
>>>
>>>
>>> > > 3) The example above, of wanting to have an API that allows explicitly
>>> > > passing in undefined to override a default value, seems outside of the
>>> > > common case (out of curiosity - are there any realistic example of this?).
>>> > >  If truly desired, it is easy to not use default values.  But the common
>>> > > case seems more likely to be to emulate what is done today - and avoid
>>> > > having any undefined values flow into the API call.
>>>
>>> > Why is the example, outside of common sense.  It is a straightforward
>>> > function to fill every element of an array with a common value. Undefined is
>>> > certain something that can be stored in arrays so why wouldn't there be
>>> > situations where where you would want to pass undefined.  Particularly if
>>> > the fill function was written by an unreformed Java programmer who used a
>>> > peculiar default fill value.
>>>
>>> The last point was why I considered it outside of the common case.  It
>>> seems unusual to intentionally want to fill with null by default, but still
>>> allow overriding with an undefined fill.  Not impossible, but I would expect
>>> this to be rare enough that I don't mind making it the one case where
>>> default values can't be used.
>>>
>>> > I agree that there is some confusion among some JS programmer about the
>>> > current missing argument default value rules.  However, I don't think what
>>> > you are suggesting is going to reduce that confusion.  I think it will
>>> > increase it.
>>>
>>> At the end of the day - I see value in enabling the patterns developers
>>> are using today to be refactorable into default values.  I worry that the
>>> current proposed semantics are too far away from what is used today to make
>>> that practical.
>>>
>>> Of course, there is enough inconsistency in what is used currently anyway
>>> - so this may be a difficult goal to achieve fully.  But I suspect that
>>> treating undefined the same as not present at least keeps things close
>>> enough the common forms below could reasonably consider migrating to default
>>> values.
>>>
>>> // All fairly common..
>>> if(!param) { param = 3; }
>>> if(param == null) { param = 3; }
>>> if(typeof param == 'undefined') { param = 3; }
>>> param = param || 3;
>>> var param = arguments[1] || 3;
>>>
>>> // Not sure I've ever seen this... which seems to be the proposed default
>>> value semantics
>>> if(arguments.length < f.length) { param = 3; }
>>
>>
>>
>> At first the answer to this didn't really matter to me, because how often
>> does someone pass undefined to a function like foo(undefined). I know I
>> don't, though I'm sure it happens occasionally. Then I thought about it and
>> realized that it happens in my code all the time, just not like that. A much
>> more common case is a pass through of an argument to another function.
>>
>>     function fadeIn(duration=200){...}
>>     function fadeOut(duration=200){...}
>>     function fadeToggle(duration){
>>         if(visible){
>>             fadeOut(duration);
>>         }else{
>>             fadeIn(duration);
>>         }
>>     }
>>
>> Here, the argument duration is always passed through fadeToggle to fadeIn or
>> fadeOut. Someone writing fadeIn would always expect to have a default of
>> 200. fadeToggle does not care about the duration so much as it wants to pass
>> it on and use the defaults of the functions it calls. If passing undefined
>> does not trigger the default, it would have to be rewritten like:
>>
>>     function fadeToggle(duration){
>>         var hasDuration = typeof duration != "undefined";
>>         if(visible){
>>             if(hasDuration){
>>                 fadeOut(duration);
>>             }else{
>>                 fadeOut();
>>             }
>>         }else{
>>             if(hasDuration){
>>                 fadeIn(duration);
>>             }else{
>>                 fadeIn();
>>             }
>>         }
>>     }
>>
>> Given this, I would probably just stick to putting
>>
>>     duration = duration || 200;
>>
>> at the top of the function.
>>
>> - Russ
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> Luke
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list