Peter Hildebrandt wrote:
Ken,
as discussed in the ECLM thread:
I look forward to the IR, maybe you have run into something I want to add to Cells to better handle things going away (a frequent problem). In my latest app I am running into a lot of problems with what is generally called referential integrity, specifically external references to kids that have been not-to-be'd. eg, my window's keep a reference to the "focus", which might be in a math problem the student decides to delete. uh-oh. Sprinkling (setf (focus w) nil) all over the place broke down when it ended up erasing a new value that had been set by code that tried to handle the problem by, say, moving the focus to the next problem when deleting the current problem.
What happens in my case is that I have one family observing another like
(defmodel observer (family) () (:default-initargs :kids (kids-list? (loop for kid in (kids (value self)) collecting (make-instance 'observer :value kid :fm-parent *parent*)))))
Then, when we remove a kid in the observed tree, its kids are declared md-dead *before* the observers on those are disposed of, and immediately cells complains about accessing a dead cell.
I am at a loss here, so any insight is greatly appreciated.
I was thinking while doing the dishes. I can image the observer class being interesting in its own right, and slots over there ending up dependent on the same original kids-list in some way, as well of course as the value of the observer. Propagation would then try to update this slot and when it got to the value of the observer find a dead instance. Any rule that got to the value of the observer by accessing the list of observers (say something iterating over them) would not encounter such an observer/value, but rules lower down that get at the value directly will.
Now normally this is not a problem because such lower down rules would tend not to depend also on the original list, and indeed the reason I have left this unaddressed is that in most cases I have seen a simple way to rewrite my rules that was even better and which did not end up with these widespread dependencies (if you have followed me so far on that, and if I hasten to add all this guesswork is on the money). I like to hold out for Real Problems before whacking away at the code, I think that is a slippery slope.
btw, all that stuff in their that worries about dead instances is preemptive safeguard stuff -- I think if you disable that most things will just work. The rules that are failing now will run harmlessly and in a few cycles everything gets cleaned up anyway. Cells ran for /years/ with this happening to no ill effect (until RoboCup, of all things).
If you want to send me your whole project I will look to see how I would rewrite the rules if that is even possible, and if not take a look at solving this formally.
fyi, in the past I have done silly things like having Cells just return nil on slot-value access to dead cells, but we may want to find something more elegant. :)
kt