Re: ConstrainDOMStringParameters would be good riddance

On 9/25/14 5:55 AM, Harald Alvestrand wrote:
> On 09/23/2014 07:47 PM, Jan-Ivar Bruaroey wrote:
>> For numeric constraints, a single value represents an ideal target, 
>> whereas a collection of values (in the form of a range) represents a 
>> requirement.
>>
> ObQuibble: A range is not a collection of values.

Thanks, a set of values is what I meant. [2]

>> Logically, why doesn't the same hold true for strings and enums?
>>
>> In other words: For string and enum constraints, have a single value 
>> represent an ideal target, and have a collection of values (in the 
>> form of a sequence) represent a requirement?
>> E.g.
>>
>>      { someEnumConstraint: "fourth" } // ideal
>>      { someEnumConstraint: [ "third", "fourth", "fifth"] // required
>
> How would we then represent "ideal: one of these, but I can live with 
> something else"?

It's a sequence, so we can put things in preferred order:

   { someEnumConstraint: [ "fifth", "fourth", "third" ] // required set, 
"fifth" is ideal

>> Unlike numeric constraints, we don't need keywords like "min" and "max":
>>
>>     { someNumericConstraint: 4 } // ideal
>>     { someNumericConstraint: { min: 3, max: 5 } } // required
>>
>> which means we don't need "ideal" and "exact" either, and can ax 
>> ConstrainDOMStringParameters [1]
>>
>> Bonus: Enums no longer require per-type changes to the spec e.g. 
>> ConstrainVideoFacingModeParameters
>
> How come?

How come we wouldn't need ConstrainDOMStringParameters? Because it's 
mostly redundant in this syntax:

      With ConstrainDOMStringParameters    | Without
----------------------------------------+---------------------------------
                                           |
   { foo: { ideal: "fourth" } }            |   { foo: "fourth" }
|
{ foo: { exact: ["third", "fourth"]} } |{ foo: ["third", "fourth"]}
|
{ foo: { exact: "third"} }             |   { foo: ["third"]}
|
{ foo: { exact: ["third", "fourth"], |   { foo: ["fourth", "third"]}
            ideal: "fourth" } }            |
|
{ foo: { ideal: ["fifth", "fourth"] } } | advanced: [
                                           |   { foo: ["fifth", 
"fourth"] } ]
|
| or
|
|{ foo: ["fifth", "fourth",
     |           "third", "second",
|"first"]} // e.g. all
|

This has semantic symmetry with numeric constraints over syntactic symmetry:

  * Sets are required (described by [] vs. {min: max:})
  * /*Actual*/ "bare" values (outside [] and {}) are ideal.


> (btw, ConstrainVideoFacingModeParameters is gone - I think the pull 
> request was yours)

Yeah by converting it to ConstrainDOMStringParameters! :-)

There's hope of using webidl enums in the future though. In any case, my 
point with enum was that when we had them their XxxParameters were a 
pain to specify, and that would be redundant too this way.

>> Simpler.
>
> But losing the ability to express a particular semantic.

Which one?

>> .: Jan-Ivar :.
>>
>> [1] 
>> http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDOMStringParameters

[2] " The range of a variable is given as the set of possible values 
that that variable can hold"
- http://en.wikipedia.org/wiki/Range_(computer_programming)