Re: ConstrainDOMStringParameters would be good riddance

High level bit: I think the proposed changes are making things more 
complex; I dislike them.

On 09/25/2014 08:51 PM, Jan-Ivar Bruaroey wrote:
> 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

Now you have introduced ordering and different weights. Your algorithm 
is becoming more complex.
>
>>> 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.
>

Not what I asked - I asked why enums would no longer require per-type 
changes to the spec.

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

|
{ foo: { ideal: ["fifth", "fourth"] } } | advanced: [
                                           |   { foo: ["fifth", 
"fourth"] } ]
|
| or
|
|{ foo: ["fifth", "fourth",
     |           "third", "second",
|"first"]} // e.g. all
|



Using advanced would express the semantic correctly, I think, but the 
other alternative requires the client to enumerate all possibilities, 
which means that nasty things could happen if the implementation adds an 
alternative the client did not expect.

(The client can find what values are possible using capabilities. This 
requires additional code.)