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

I'm glad that you have given an example of where this all actually
matters.  Thank you for that.

So now we know what the design trade-off is.  Our options are:

A.  Make an API that prevents errors from occurring when foo(bar) is
expected to mean foo(bar, false), at the cost of making the API call worse
(for example, addTransceiver({send: "inactive"}) instead of
addTransceiver({send: true})).

B.  Make the API call better (for example, createDataChannel({ordered:
false}) instead of createDataChannel({order: "unordered"}) at the cost of
making it possible to have errors when foo(bar) is expected to mean
foo(bar, false).


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?

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!




On Sun, Feb 21, 2016 at 8:31 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/21/16 11:01 AM, Jan-Ivar Bruaroey wrote:
>
> On 2/20/16 2:36 AM, Peter Thatcher wrote:
>
> So how are we better off with an enum in this case?
>
>
> Because there's precedent for expecting undefined to be interpreted as
> false [1], and no such precedent for strings?
>
>
> For example, imagine this code in your company's source tree written by
> someone else:
>
>     function foo(label, ordered) {
>       pc.createDataChannel(label, {ordered: ordered ? true : false });
>     }
>
> then someone touching that area might feel compelled optimize it to:
>
>     function foo(label, ordered) {
>       pc.createDataChannel(label, {ordered: ordered });
>     }
>
> except today they'll unwittingly have introduced a bug, because elsewhere
> in the tree people readily expect these two calls to mean the same:
>
>     foo("label", false);
>     foo("label");
>
> and in the second case, the person touching the code will have subtly
> changed data channels to be ordered, which was not their intent.
>
> If instead the code looked like this:
>
>     function foo(label, ordered) {
>       pc.createDataChannel(label, {ordered: ordered ? "ordered" :
> "unordered" });
>     }
>
> then there is no obvious optimization.
>
> .: Jan-Ivar :.
>
>