Re: [Bug 26526] Fix aspect ratio constraint

On 15/08/2014 12:35 PM, Jan-Ivar Bruaroey wrote:
> On 8/15/14 4:08 AM, Harald Alvestrand wrote:
>> When something's a number in Javascript, it's perfectly legal to 
>> write an expression like 16/9 in that space.
>>
>> Your other alternatives - { num: 16, den: 9 } and "16/9" - are, to 
>> me, more complex and less readable - the author has to remember that 
>> while he thinks of it as a number, he has to remember that there is a 
>> special syntax that is only used for expressing numbers in this 
>> particular place.
>>
>> Specifying an epsilon allows the author to write the number in most 
>> fashions he's used to, and have the result of the comparision be the 
>> same.
>>
>> I believe the epsilon solution is the easiest one for authors.
>
> +1 on 16/9 (or width/height for that matter) being the ideal JS 
> expression, and on the alternatives being atypical.

I'm with Silvia on this: "16/9" is exact and readable. The fact that the 
author has to remember to use a String instead of a Number is not a 
readability concern, it is a question of whether the API is intuitive 
(behaves as expected without users having to read the documentation).

I agree that 16/9 *looks* more intuitive than "16/9" but it *behaves* 
less intuitively.

Looks: if we require a String and the user passes a float, the system 
will fail-fast and little harm is done.

Behavior: when the user specifies 16/9 he means *exactly* 16/9, not some 
approximation. The epsilon you mentioned might work today but will break 
in unpredictable ways in the future (as implementations are exposed to 
resolutions we did not foresee ahead of time, such as 4k). In that case, 
the float comparison will fail and the system will violate the principal 
of least surprise.

> Nobody NEEDS to specify an aspect ratio of 1.3334 and not have it 
> match 1.3333.

You don't know that. You have no way of predicting what kind of 
resolutions webcams will support, or what level of accuracy users will 
want/need in the future. You're forcing implementation details on 
end-users instead of hiding them under the hood. You shouldn't make such 
a decision purely for the sake of simplifying the algorithm 
implementation. Implementation details change over time, but API design 
is locked for life.

Gili