- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 11 Nov 2013 12:30:40 -0800
- 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