On Tue, Apr 22, 2008 at 2:31 AM, Ken Tilton kennytilton@optonline.net wrote:
<g> We might be on the same page talking different languages and that is the problem: cells get optimized away when they are "unlinked" to a dependency. You created dependency links in another language if you will and something got lost in translation (great movie).
Can you re-implement such that the linking API Just Works(tm)?
Now I see what you mean (and what I was afraid of when I wrote "not on the same page") -- I had a dim feeling that there must be some sort of linking mechanism in cells already, and that I was pretty much duplicating existing machinery. But my approach worked so nicely (and was so easy to code) that I did not want to bother learning too much about cells internals.
Oh well, I have lots of Real Work to do this week (gotta move along with my thesis writing. Now that I have a job waiting for me in July, I better make sure I'm done by then) -- but I'll try and see whether I can figure out how it *should* work.
Then, of course, this leads us to different kinds of links - "c_when": Link if there is something in the store associated with :key at the time the cell is evaluated. If the linked object is removed from the store, the link dies. If not, just die silently. - "c_1": Like c_when, but if there is nothing stored, wait until the slot is filled the first time, then establish the link. - "c?": Like c_1, but if the linked object is removed, revert to default,and wait until the slot is filled the next time.
c_1 would be what is needed in GUI stuff -- i.e. we wish to forward reference another GUI element and link when it is instantiatied, but we don't really need to do anything when the whole GUI is discarded.
Well, hopefully writing goes well the next couple days and I'll have some time to play with this.
Cheers, Peter