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

Re: APIs that have boolean arguments defaulting to true

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 12 Nov 2013 08:27:51 +0800
Message-ID: <CA+c2ei9SMEkB8JR-n9-Wysnccbf32x7k29ieuQ-mK0pahQhPig@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC