W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2016

Re: Using enums to avoid default true in "settings dictionaries" (#466, #467, #471)

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 24 Feb 2016 08:10:28 -0800
Message-ID: <CAJrXDUEx2xKwn82p8dM9EKoQ0VA1Akwo5PpxAa3A_p5wSn_wgA@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On Tue, Feb 23, 2016 at 10:48 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/23/16 6:30 PM, Peter Thatcher wrote:
>
> My opinion: B is better than A.  I have no sympathy for someone calling
> foo(bar) and expecting it to be the same as foo(bar, false).  This is JS,
> which does all kinds of bizarre things with undefined/false values, and
> that's just asking for pain.  For example, what if foo() does addition?
>
>
> And I have no sympathy for someone doing boolean addition.
>
> function foo(bar, baz) {
>   return bar + baz;
> }
>
> foo("bar") // "barundefined"
> foo("bar", false)  // "barfalse"
> foo(1, undefined)  // NaN
> foo(1, false)  // 1
>
> Not the same!
>
>
> Lets return from WAT!-land and use booleans correctly, in conditions:
>
>
​This is Javascript.  There is not return from WAT-land.​



> function foo(bar, baz) {
>   return baz ? bar : null;
> }
>
> foo("bar") // null
> foo("bar", false)  // null
> foo(1, undefined)  // null
> foo(1, false)  // null
>

​Do you really think all of the Javascript in the world uses booleans
"correctly"?
The assertion that foo("bar") == for("bar", false) in all cases is false.
A developer can't rely on it, and shouldn't rely on it.
​
I don't think we should make our API worse to
​trying to maintain this false expectation.

​If we can come up with a strong argument for making our API worse, I'm
willing to hear it.  But I'm not convinced by this one.





>
>
> .: Jan-Ivar :.
>
>
Received on Wednesday, 24 February 2016 16:11:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 February 2016 16:11:37 UTC