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

On Wed, Feb 17, 2016 at 11:51 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 18 February 2016 at 03:50, Peter Thatcher <pthatcher@google.com> wrote:
> > I'm left wondering: if it's just "bad WebIDL form" to have true-ish
> > defaults, why don't we just leave the defaults "undefined" and make the
> > meaning of "undefined" on dictionaries, when passed in their respective
> > methods, be "ordered data channel", "sender is active", "receiver is
> > active", and "VAD is enabled"?  Wouldn't that be a lot more simple?
>
>
> That would be adherance to the letter of the law, but spitting on the
> spirit of it.  This guidance exists for a reason.
>

​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?

Can you please explain or provide me to a link that explains the spirit of
the law and it's good reasons?  I'm having a hard time making good design
decisions without understanding what things are bad and why they are bad.


> I agree that these are somewhat tricky.  These are features that we
> have agreed need certain defaults.  If we weren't so reliant on
> dictionary passing, we could leave no direct parameters for each of
> them and do this:
>
> sender.disableVoiceActivityDetection();
>
> Or, if you want to get fancy, you could phrase disablement as a "feature":
>
> { sendSilence: true }
>
​
The dictionaries only exist as away to avoid having a very long list of
parameters on a method, and to make call sites more readable.  Is there
another way that I'm not familiar with?


As for using methods, I RtpTransceiver methods don't sound so bad:

var video = addTransceiver("video");
video.deactiveSender();  // Opposite of activeSender()
video.deactiveReceiver();


But I don't think that a method like
DataChannel.enableReceivingMessagesOutOfOrder() would work well.