Re: APIs that have boolean arguments defaulting to true

On Tue, Nov 12, 2013 at 3:37 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> This does mean that we can't have "foo()" with no arguments default to true,
> so we should probably design APIs such that "false" gives the sane default
> behavior if there's an optional boolean argument at all.

Yup. Arguments defaulting to true has always seemed surprising to me.
WebIDL, default behavior for explicit undefined, etc aside, a missing
argument always looks falsy to me. The fact that it isn't in XHR.open
took me quite a while to get used to.

When possible it's probably better to use separate signatures as
Garrett points out. When that's not practical (constructors, multiple
booleans, etc) swapping the meaning and defaulting to false seems like
the way to go.

I would probably go even further and say that having string arguments
that default to something other than the empty string, or numeric
arguments default to something other than 0, or objects that default
to something other than null, in cases where empty string/0/null is
valid values, seems like a bad idea to me.

/ Jonas

Received on Tuesday, 12 November 2013 00:28:49 UTC