undefined being treated as a missing optional argument

Axel Rauschmayer axel at rauschma.de
Fri Apr 13 10:16:05 PDT 2012


It’s an interesting case of “traditional lenient style” versus “new, more strict style”. Both approaches have merit (pro leniency: familiarity, compatibility). With arity checking, a first step towards the latter style has been made, I think it makes sense to continue in that direction.

On Apr 13, 2012, at 18:50 , Russell Leggett wrote:

> 
> I'd write it:
> 
>     function fadeToggle(...args){
>         if(visible){
>                 fadeOut(...args);
>         }else{
>                 fadeIn(...args);
>         }
>     }
> 
> If you don't care about the the actual argument values are just passing them on that's how you should do it.
> 
> Ok, sure, but in an equally likely case, only one of the arguments is a pass through, should you still use ...args for one thing just to distinguish? What about other case like objects with optional properties fadeIn(config.duration)?
> 
> I just don't understand why someone who wanted to be able to distinguish between missing and undefined would really need the extra convenience of default parameters. What are they going to default to - undefined? Meanwhile, the rest of the people that probably could use it all the time to replace their foo = foo || "default" code have to keep it around. I understand what you're saying in principle. There is a certain amount of purity and correctness to it, I just don't think its practical.
> 
> - Russ
>  
> 
> Allen
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120413/47670c96/attachment-0001.html>


More information about the es-discuss mailing list