Processing Constraints, a solution

Yesterday I ran into a conundrum processing the constraints of options. I had a solution but I wasn’t happy with the cleanness of it. I slept on it and this morning I’ve got something I’m much happier with.

Instead of summering the constraints in a structure like this:

driver => option =>  printer => [sense, default]

I used a structure like:

printer=> driver => option => [sense, default]

If a constraint does not specify a printer then it goes under the ‘*’ printer hash, like wise a driver can also be ‘*’.

This also allows me to simplify retrieving the constraints by merging it with the operation that determines which options to inspect for a particular driver printer pair. This happens in the function getOptions($relations, $printerName, $driverName), which now only merges the lists of options from the three possibilities (driver, printer, and driver-printer) overwriting keys with those of more specific possibilities.

Now I can move onto equivalency testing of parseCombo and the C implementation.

1 thought on “Processing Constraints, a solution

  1. Pingback: Processing Constraints, a conundrum @ Daniel Dressler

Leave a Reply

Your email address will not be published.