Some thoughts about the future of interacts

Things to be able to do:

Separating controls and variables

William's implementation makes it easy to create graphical control, and provides a way to easily get and set the value of the control.

My way separately provides an easy way to create a variable where changes are tracked and notified, and separately provides an easy way to create a control reflecting the value of a variable or expression.

William's way explicitly ties each control to a chunk of code that gets evaluated whenever a control in the control group is updated. My way does not. It provides a way to tie a chunk of code to a variable, but it is not necessary.

William's way forces each control to belong to a namespace (same with mine) and also forces all updates to execute a specific piece of code (and only execute a specific piece of code). All update logic must be in that function. Hmmm..that is nice.

My way forces each control to belong to a namespace, but the update logic can be spread around since updates happen to all dependencies. Is that better? It's more flexible, but it's also more complicated since logic is spread around in different places.

A serious problem with my implementation right now is that a variable update requires:

Here are two ways to overcome this problem:

interact/future (last edited 2013-03-01 15:52:52 by jason)