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

On Thu, Feb 25, 2016 at 11:21 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/24/16 11:10 AM, Peter Thatcher wrote:
>
> On Tue, Feb 23, 2016 at 10:48 PM, Jan-Ivar Bruaroey < <jib@mozilla.com>
> jib@mozilla.com> wrote:
>
> 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"?
>
>
> That's a straw man argument. Boolean is well-defined in both JavaScript
> [1] and WebIDL [2].
>
> 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.
>
>
> Again, a straw man. It doesn't have to be true in all cases to be a common
> pattern.
>
> ​
> I don't think we should make our API worse to
> ​ trying to maintain this false expectation.
>
> ​If we can com​
>
> ​I think you're missing the point.  Let's back up a little.

The original question in this thread is: should we change our API to head
avoid a possible "hazard"?

My question to that was: what is the hazard?

So far, only 2 examples have been presented.  The first isn't helped by
changing the API to enums.  The second is only to safely allow foo("bar",
false) to be replaced with foo("bar") under certain circumstances.

And my response to the second is: that's something silly to do anyway, so
it doesn't seem at all worth it change our API to support that.

Are there any other examples?




> FWIW, I think we need a strong argument to disregard an explicit warning
> in WebIDL [3], and I haven't heard one.
>
> [1] https://tc39.github.io/ecma262/#sec-toboolean
> [2] https://heycam.github.io/webidl/#es-boolean
> [3] https://heycam.github.io/webidl/#dfn-dictionary-member-default-value
>

​I haven't yet heard a good reason *to* follow the warning in our
particular case.  As I mentioned, I've only seen 2 examples of the
"hazard", and neither of them are compelling.

There is a very clear reason to *not* follow the warning:  It makes our API
calls worse.  We've tried many times, and we can't come up with something
that avoids the hazard without being very ugly.


>
>
> .: Jan-Ivar :.
>
>