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

And I'm wrong.

I just tested it on our webidl compiler, and it still happens (undefined 
is interpreted as "enabled"), because dictionary [1].

So the only difference here would appear to be mental: In that, 
undefined, being falsy, is arguably a valid input to a boolean, i.e. 
users might reasonably expect undefined to produce false, not true, and 
they would be right.

With enum, they would be wrong. So the only difference with enum seems 
to be who's wrong? :)

Kind of a weak argument for change. We might want to check back with 
folks and see if they still think it's important, given the identical 
dictionary behavior?

.: Jan-Ivar :.

[1] I found some text in https://heycam.github.io/webidl/#changes to 
support this: "Changed the ECMAScript to IDL dictionary conversion 
algorithm to treat a property with the value undefined as missing."

On 2/17/16 8:39 PM, Jan-Ivar Bruaroey wrote:
> On 2/17/16 3:54 PM, Peter Thatcher wrote:
>> Sorry for my ignorance of WebIDL-ish things, but I still don't 
>> understand how using a enum value as the default is different.  The 
>> only "bad case" I've seen is that we wouldn't want 
>> "createOffer({voiceActivityDetection: undefined})" to send VAD, but 
>> even with the default being an enum, that still happens, doesn't it?
>
> Webidl enums are strings [1], and according to ToString() [2] 
> undefined turns into "undefined", which I suspect throws as invalid 
> input for this enum, so it shouldn't happen (though I should test it).
>
> That's my understanding anyway,
>
> [1] https://heycam.github.io/webidl/#es-enumeration
> [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tostring
>
> .: Jan-Ivar :.