while i will go off and read a few of the linked papers, this post doesn't do a great job, in my opinion, of showing a meaningful relationship between generalized constraint solvers and one-way dataflow constraints. i use one-way dataflow constraints because they are simple/natural/expressive. generalized constraint solvers are vastly more general, and i can't see how they would apply in a non-geometric setting. isn't cassowary only really interesting when there are inequalities? when there are only equalities, isn't the system either over-constrained (bad) or not (fine)? (to be fair, i haven't read the cassowary paper.) would i ever want code that expresses an object in terms of an inequality with another object? will i ever care about cyclic graphs of constraints between objects that actually require a solver to determine if they are over-constrained, and will any solver be able to do the right thing without knowing some properties of the constraints (e.g. linearity)? (cycles are the one thing i'm careful to avoid when i write one-way dataflow constraints in e.g. MVC code.)
back
2 comments
If you are already using one-way dataflow constraints, you weren't exactly the target audience for my writeup, which was trying to introduce this body of work to devs who may only be familiar with the pale imitations. I am a bit surprised that you are careful to avoid cycles, even the one-way solvers I mention handle those.
I also think that the one-way solvers are the most immediately useful. On the other hand, the linguistic support needed for a pluggable one-way solver seems very similar to that needed for other solvers, and yes, they can be quite useful in more general circumstances. After all there is a whole field and several companies that do this sort of thing commercially.
fair enough that maybe i'm not in the target audience. and perhaps i'm too stuck in my own head, writing iOS apps, where i can't imagine general constraint solvers being used to solve a software-design problem (as opposed to an algorithmic problem, where it certainly does make sense). i am genuinely curious - are general constraint solvers useful as a software-design pattern?
are one-way dataflow constraints really any different from the observer pattern? i avoid cycles exactly because i implement it myself, and don't even have a solver, per se. even KVO seems not to handle cycles. and when e.g. i am using auto-layout in IB, even then i am careful to avoid over-constrainedness, even though the solver can settle on a "solution."
True .. and while I revisit the linked references some of which I'm familiar with (fran and ilk, for ex), I'd like to point out that having the list of references at the bottom of the post of something would be much more handy than scanning the text for normal words with weird colours. The traditional paper format is awesome for readability when dealing with material that references a lot.