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

Re: APIs that have boolean arguments defaulting to true

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 11 Nov 2013 12:30:40 -0800
Message-ID: <CAAWBYDCJT1FQPGbdmvz+9+_mQbS4Bqum1mGPwkTg+m2jk8T89Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Nov 11, 2013 at 11:37 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Dear all,
>
> One take-away I have from the current attempts to make undefined be treated
> as missing is that we should avoid creating APIs that have arguments of the
> form "optional boolean arg = true".
>
> The reason for that is that I think the behavior of such an argument when
> combined with the conventions for undefined is very surprising. Consider a
> function declared as:
>
>   void foo(optional boolean arg = foo);
>
> and these two patterns of calling it:
>
>   if (myValue) {
>     foo(true);
>   } else {
>     foo(false);
>   }
>
> and
>
>   foo(myValue);
>
> These two patterns have different behavior, which seems very unintuitive to
> me and to everyone else I've pointed this out to...
>
> 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.
>
> Thoughts?

Yes.

~TJ
Received on Monday, 11 November 2013 20:31:27 UTC

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