Re: Removing the concept of "optional any"

On Feb 19, 2014, at 1:30 PM, Jonas Sicking wrote:

> On Feb 19, 2014 12:17 PM, "Domenic Denicola" <domenic@domenicdenicola.com> wrote:
> >
> > I think in general functions that treat not-passed as different from undefined are *very* surprising and un-JavaScript-ey; I feel like we've discussed this on this list many times before. `arguments.length` is the only way to create such functions, and that will be even less possible in ES6 given the function forms for which `arguments` is not present.
> >
> > I don't know what behavior is most appropriate for `postMessage()` but it should be the same as the behavior for `postMessage(undefined)`.
> 
> Rather than talk in generalities, I'd really prefer to talk about specific examples.
> 
> `postMessage(x)` sends the javascript value in x to the receiver. Our aim has been that any values other than callable objects are valid values.
> 
> `cursor.update(x)` saves the javascript value in x to the database. Our aim has been that any values other than callable objects are valid values.
> 
> What behaviour do we want in these two specific cases when x is omitted. I.e. what makes the best API.
> 
> I can both see the argument "if you were to naively implement this in JS omitting x should be equivalent to x === undefined" and "omitting x is clearly a bug, throw an exception".
> 
> I just don't know which argument is stronger.
> 
> 

By now, this is probably piling on...

If undefined ever a valid message or for a valid value to put into the data base?  If so, then I would treat () for either as (undefined).  If undefined is never valid then I would throw on either () or (undefined), but because undefined is an invalid argument value, not because the wrong number of arguments.