[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