
The Siren Call of KVO and Cocoa Bindings - mpweiher
http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html
======
doxydexydroxide
You missed VPRI KScript implemented in squeak smalltalk.

Massive performance issues and unresolved Glitch issues.

KScript and KSWorld: A Time-Aware and Mostly Declarative Language and
Interactive GUI Framework
[http://www.vpri.org/pdf/tr2013002_KSonward.pdf](http://www.vpri.org/pdf/tr2013002_KSonward.pdf)

Toward the Future of Personal Computing System Construction
[http://www.vpri.org/pdf/M2013004_agere.pdf](http://www.vpri.org/pdf/M2013004_agere.pdf)

And the works of Sean McDermid Roly Perera and dm barbour (AWELON Blue)

~~~
mpweiher
There are _tons_ of systems I did not mention, the field is quite large. Just
start with the references I gave and continue down the rabbit hole :-)

I am quite aware of KScript and KSWorld, in fact one of the authors shares an
office with me, though we are both not in that often. These are highly
experimental systems, so they didn't quite fit into my narrative.

------
mikhael
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.)

~~~
mpweiher
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.

~~~
mikhael
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."

------
Thomas-Paris
The Garnet and KR work you cited from CMU is what got me into
constraints/declarative OO/FRP. The term I best like for this style is
"Dataflow". Cells, which is/was a dataflow extension for CLOS (object oriented
Lisp) used this term, and uses both lazy and eager dataflow.

It was a huge amount of fun to work in, because it made GUI and server
programming amazingly productive for a small team. You could get things
working super fast, and with very little bugs because so much of the
bookkeeping was done for you.

And one of the secrets compared to other systems in this vein was exactly the
eager default, with a lazy option. By choosing per-formula which model you
wanted, you could use the system that handled the most bookkeeping for you.

The Lisp code is still here:

[http://common-lisp.net/project/cells/](http://common-lisp.net/project/cells/)

The old examples and so on are in the Internet Archive:

[http://web.archive.org/web/20081026054504/http://www.tilton-...](http://web.archive.org/web/20081026054504/http://www.tilton-
technology.com/cells_top.html)

------
DenisM
No mention of SQL? Relational algebra is a very prominent example of one-way
constrain system, if you look at individual nodes in the query execution tree.
Also, remember to consider index maintenance and materialized/indexed views.

I like that article is well-researched with references to various papers,
there is definetly some good reading material there.

------
DenisM
KVO is akin to manual memory management - a lot of individual pieces to tweak
and remember, and the outcome is very brittle and error-prone.

I prefe the approach where dependant values are expressed as functions, and
then a caching layer is added where needs for performance.

~~~
archagon
How is it "brittle" and "error-prone"? You create your model object and KVO
observe its properties from the controller. How much simpler and more
decoupled could you get? If you're using MVC correctly, it seems to me that
the pieces just naturally fall into place. You also get the benefit of being
able to change your model from elsewhere in your program, or even swap it out
completely, and have it automatically reflect in your view.

(On the other hand, if your app is not model-based, I can see how it could get
unwieldily.)

~~~
dmur
The promise of simplicity does not match the reality. It's explained well
here, this was linked in the article too: [http://khanlou.com/2013/12/kvo-
considered-harmful/](http://khanlou.com/2013/12/kvo-considered-harmful/)

------
lupinglade
KVO and Cocoa Bindings are not the same thing. Just because Bindings use KVO
does not mean both technologies are alike. KVC/KVO has many uses outside Cocoa
Bindings or UI updates. Further, obviously KVC/KVO has a performance penalty
and that is exactly why you would not use it for high performance tasks.
However for just about everything else it is a great tool and will minimize
the amount of code you write greatly, resulting in improved maintainability.

~~~
mpweiher
"KVO and Cocoa Bindings are not the same thing"

Yes. From the Fine Article:

"[..] bindings are one-way dataflow constraints, specifically with the
equation limited to y = x1. More complex equations can be obtained by using
NSValueTransformers. KVO is more of an implicit invocation mechanism that is
used primarily to build ad-hoc dataflow constraints."

Bindings: simple one way dataflow constraints.

KVO: implicit invocation.

Not the same thing.

------
thewarrior
Ive begun learning Reactive Cocoa and I feel that it does most of what you
mentioned your post except that the syntax quite unwieldy. Maybe some higher
language that compiles down to it just might do the trick.

~~~
seivan
I am probably going to be downvoted by have you had a chance to look at
[https://github.com/seivan/SHRACComparison](https://github.com/seivan/SHRACComparison)
and maybe
[https://github.com/facebook/KVOController](https://github.com/facebook/KVOController)
\- you really don't need RAC to use signals.

------
coreload
See also
[http://jeffsutherland.org/oopsla98/nakamura.html](http://jeffsutherland.org/oopsla98/nakamura.html)

