[PEAK] Generalizing cells and data structures

Phillip J. Eby pje at telecommunity.com
Tue Aug 28 21:17:15 EDT 2007


While working on the detailed specification for the new Trellis 
recalculation algorithm, it has occurred to me that there might be a 
way to do without having "cell" objects as a special type, thereby 
making it easier both to create specialized cells, and to create 
"cell-ish" data structures.

I had already been planning to give the _Controller class more 
responsibility and make it more public, but while working on the spec 
I noticed that nearly all the complexity of cell implementation can 
be delegated to the controller.

For example, suppose the controller had methods like:

changed(ob, undo_func=None, *args)
     Record a change to 'ob'; calling undo_func(*args) will revert 
the change (unless it's None, in which case the change had no actual effect)

used(ob)
     The value of 'ob' has been used in some way

calculate(ob, expr, notify_func)
     Return the value of expr() (after first undoing any operations 
that occurred during the previous calculation of 'ob'), and arrange 
for "notify_func(ob)" to be called if any objects "used()" during the 
calculation are "changed()" afterward.

These three methods could encapsulate most of the algorithm 
complexity, but would be easy to call from data structure types to 
indicate changes.

I'm not quite clear yet on how to integrate this with layers and 
queueing.  A cell with a rule would need to have a way, when read, to 
know whether there were any notifications pending for it (so that if 
you try to read the rule, it can go ahead and 
recalculate).  Alternatively, the callers would need to handle layers 
and queueing themselves.

This also doesn't cover @modifier, @action, and @task rules yet, 
although those should also be a straightforward extension.

So tomorrow, I'm going to see whether this approach can be cleanly 
extended to handle the rest of the design, but I just wanted to toss 
this out there and see what people think, as far as whether this is a 
more understandable API for building observable data structures.




More information about the PEAK mailing list