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

If we leave everything as-is and accept the change that {send: false,
received: false} turns into {direction: inactive}, and similarly for the
other 3 combinations, I can live with that.

Then we just need to bikeshed the names for
sendrecv/sendonly/recvonly/inactive.

In other words, I support this proposal (1 day late).

On Wed, Apr 27, 2016 at 3:24 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> 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)?
>
> /Adam
>
>
>