- From: Mark S. Miller <erights@google.com>
- Date: Mon, 11 Nov 2013 12:13:05 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
Received on Monday, 11 November 2013 20:13:32 UTC
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.
>
I would indeed recommend that as a best practice but not a requirement. For
exactly the reasons you state.
>
> Thoughts?
>
> -Boris
>
>
--
Cheers,
--MarkM
Received on Monday, 11 November 2013 20:13:32 UTC