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.
Pingback: Processing Constraints, a conundrum @ Daniel Dressler