- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 23 Feb 2016 09:16:48 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, Peter Thatcher <pthatcher@google.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2016-02-21 17:32, Jan-Ivar Bruaroey wrote:
> On 2/21/16 11:01 AM, Jan-Ivar Bruaroey wrote:
>> On 2/20/16 2:36 AM, Peter Thatcher wrote:
>>> So how are we better off with an enum in this case?
>>
>> Because there's precedent for expecting undefined to be interpreted as
>> false [1], and no such precedent for strings?
>
> For example, imagine this code in your company's source tree written by
> someone else:
>
> function foo(label, ordered) {
> pc.createDataChannel(label, {ordered: ordered ? true : false });
> }
>
> then someone touching that area might feel compelled optimize it to:
>
> function foo(label, ordered) {
> pc.createDataChannel(label, {ordered: ordered });
> }
>
> except today they'll unwittingly have introduced a bug, because
> elsewhere in the tree people readily expect these two calls to mean the
> same:
>
> foo("label", false);
> foo("label");
>
> and in the second case, the person touching the code will have subtly
> changed data channels to be ordered, which was not their intent.
>
> If instead the code looked like this:
>
> function foo(label, ordered) {
> pc.createDataChannel(label, {ordered: ordered ? "ordered" :
> "unordered" });
> }
>
> then there is no obvious optimization.
On RTCDataChannel we have an oredered attribute, that reflects the
ordered setting used to create the object. If we want to be consistent
on the type it gets a bit strange if people try to use it as a boolean
(which the name suggests it is).
var dc = pc.createDataChannel(label, {ordered: "unordered"});
!!pc.ordered is true (since !!"unordered" is true)
/Adam
Received on Tuesday, 23 February 2016 09:17:22 UTC