W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2016

Re: Proposed resolution on the "change booleans to enums" issue

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 27 Apr 2016 10:24:08 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B3158890296B2B2B@ESESSMB307.ericsson.se>
On 2016-04-27 12:05, Harald Alvestrand wrote:
> Den 27. april 2016 11:58, skrev Adam Bergkvist:
>> On 2016-04-19 18:53, Harald Alvestrand wrote:
>>> Over the last few weeks, we’ve had a long drawn out discussion based
>>> around the following github issues and PRs:
>>> - PR #466 “Use an enum to describe directionality of RTP stream”
>>> - PR #467 “Use enum for voiceActivityDetection”
>>> - PR #471 “Use enum for RTCDataChannal’s ordered attribute”
>>> These are based on issue #375, “true as default values for dictionary is
>>> bad practice”.
>>> Among the arguments fielded are:
>>> - Following the WebIDL spec’s advice is a Good Thing in general
>>> - Changing interfaces that people have implemented for aesthetic reasons
>>> is a Bad Thing in general
>>> - Double negatives (disableX = false) is a Bad Thing and should be avoided
>> I think this argument is a red herring. The double negative would
>> basically only exist in our IDL definitions, since there's no good
>> reason to explicitly specify the default value again. When used in code
>> it would actually be { disableVoiceActivityDetection: true }, which is
>> pretty descriptive of what the intention is: Disable the feature that is
>> enabled by default.
> I think of the snippet in "disableVoiceActivityDetection: false" as a
> double negative - you tell the code explicitly to not turn something off.
> And that will appear in code.

If I wanted to use VAD, would specifying false explicitly mean something 
else that not specifying anything at all (since the default value is 
false already)?

Received on Wednesday, 27 April 2016 10:24:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC