Re: Bare values read as "just this value please"

On 8/1/14 2:29 AM, Martin Thomson wrote:
> On 31 July 2014 17:13, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> A plain value literally is mutually exclusive with {}, almost exactly like
>> specifying a value is mutually exclusive with providing ranges and/or hints
>> for that value. To me it reads as "just this value please", yet users may
>> get cameras that are not 1280 wide or 1.78 aspect here, even though these
>> values are specified in the top "required" section.
> The top section is not "required".

Well, min, max and "exact" values only take on the meaning of being 
required when used in the top section, whereas in the advanced array 
they are optional:


        Constraint modifier:

 


        Top-level:

 


        Advanced-array:

Min
 mandatory
 optional
Max
 mandatory
 optional
Exact
 mandatory
 optional
Ideal
 ideal
 undefined I believe


In other words, our constraint-modifiers have different semantics in 
different places. We need meaningful ways to talk about this locative 
difference or our semantics are going to be hard to describe.

I agree with you that I cannot now call it the "required" section, 
indeed that is my complaint. I'm bemoaning the lack of consistency we 
bring by effectively inverting the intuitive meaning of plain values. 
Surely it follows that this complicates our semantics when we cannot 
refer to the top-level as something functionally informative like the 
"required" section.

>    And "please" is the perfect way to phrase a request (as opposed to a demand).

I find it works for demands as well. It never hurts to be polite. ;-)

>> Add to this that plain values in the advanced array are not ideal, and it's
>> a semantic mess.
> I think that bare values could equal anything and we get the same.

Hopefully I've disproved this above (i.e. follow pattern = less mess), 
but if not:

That the "exact" keyword would disappear from the vocabulary if we 
followed the pattern, should be a simplification in itself, as today it 
exists solely to support the inversion.

And this needlessly complicates enum series: Whereas a range of scalar 
values are implicitly mandatory, a series of multiple enumerated values 
are now not:

   foo: { min: 3, max: 5},             // is implicitly mandatory
   bar: ["third", "fourth", "fifth" ], //is implicitly ideal

which is confusing I think.

> Besides, anything in the advanced array is closer to ideal than a hard
> requirement, since if the set of values can't be achieved, it moves on
> to the next option.

Ideal and optional are not the same thing.

In the "min distance" algorithm recently posted, ideal does not act like 
a constraint or interact locally with other constraint-modifiers around 
it, and is instead considered globally as a property at the very end of 
everything, after the advanced array has completed. I think of it as 
gravy rather than a constraint, as in: narrow down sources by all (real) 
constraints first, and, gravy!, more than one, cherry-pick the best of all.

In the advanced array on the other hand, all rules are local to the 
entry being considered and all constraints interact equally, whether 
they are min, max, or plain values. This is important because all 
constraints within a single entry must be satisfied for that entry to be 
applied, so thinking about plain values as ideal would be a mistake 
here. Example:

   advanced: [
      { width: { min: 100, max: 1000 },frameRate: 0 }
   ]

Would never apply the width constraint. FrameRate=0 is an equal 
requirement, not a would-be-nice.

So while optional and ideal may have similar outcomes, they have 
different semantics.

Lastly, there's the wort that exact and ideal have no meaning in the 
advanced array while their siblings min and max do.

>> Is it truly too late to rectify this?
> It's never too late to fix actual problems.  We just have to agree
> that there is an actual problem.  I don't see an actual problem here.

I'd feel better if we could get to: yes we agree the semantics are 
harder, but we think the benefits outweigh the complexity. Just to rule 
out miscommunication.

.: Jan-Ivar :.