Re: Bug 23935 - Proposal: New syntax for constraints

On 14/12/2013 2:29 PM, Jan-Ivar Bruaroey wrote:
> On 12/14/13 12:21 PM, Jan-Ivar Bruaroey wrote:
>> The order is preferred order as you expressed it.
>
> That said, you can probably change the order without consequence in 
> this case since sets are likely one aspect or the other, not both.
>
> I.e. this is the same (also assuming we'll reasonably 
> approximate-compare aspects, which I suggest we mention in the spec btw):
>
> [
>  {aspect:1.33, width: 1200, height: 900 },
>  {aspect:1.33, width: { min: 800, max: 1600 }, height: { min: 600, 
> max: 1200 } },
>  {aspect:1.77, width: 1600, height: 900 },
>  {aspect:1.77, width: { min: 1280, max: 1920 }, height: { min: 720, 
> max: 1080 } }
> ]

Not DRY, but yes I find it more readable.

I still lean very heavily against the use of a declarative syntax, but I 
don't have any concrete counter-examples to provide at this time. I 
think a declarative syntax is like XML: great for computer consumption, 
terrible for human beings. Every time I've had the displeasure of 
dealing with a declarative syntax (e.g. Apache Maven, SQL, etc) it meant 
giving up control of evaluation order. Initially that didn't seem like a 
big deal, but after using the library for a few months I routinely kept 
on running into problems related to evaluation order. It is a pain in 
the ass.

A Javascript API will always be more flexible than a declarative syntax, 
and we can provide a DSL to make its use less verbose. I think it's 
always preferable to stack a simplified API on top of a more flexible 
low-level API (and expose both to the user). If you start with a 
simplified API at the bottom, you are stuck with its limitations/quirks 
forever. What seems like a reasonable limitation today may turn out to 
be a curse tomorrow.

Just my 2 cents.

Gili

Received on Monday, 16 December 2013 03:24:33 UTC