[Borges-users] controller and delegate

[Слепнев Владимир]

>If you change the delegate of a Controller, then backtrack in your
>history, the delegate must still exist in order for you to perform 
>any
>operations on it.  If @delegate is not a StateHolder, then the 
>delegate
>will be the current delegate, maybe not what you want.
>
>(I think this is correct, with a further explanation of why you think
>this is wrong, I may be convinced otherwise.)

Delegate shouldn't be a StateHolder. Let's say controller A delegates 
to controller B. 

1) If A is registered for backtracking, its instance variable 
@delegate will be snapshotted every time we request a page. So, 
@delegate needn't be a StateHolder - we get the backtracking for free. 
I've tested it.

2) If A isn't registered for backtracking, we shouldn't take the 
trouble to ensure proper backtracking in the first place.

>It is not appropriate for every Controller to register itself for
>backtracking, note that only Borges::Path and Borges::Counter 
>register
>themselves for backtracking in the built-in components.

I think this is a bug, which stems from the illusion of having the 
pages "backtracked properly" in Internet Explorer's cache. The caching 
should be turned off, as I once wrote. Or hit 'refresh' after each 
'back'. This way, a lot of stuff that isn't registered for 
backtracking will get broken. Avi Bryant said in his blog that we 
should perform the snapshot-restore trick with the registered objects 
and with them only: see 
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3240140310

>> 2) Controller#delegate_to saves the previous delegate in a local 
>> variable 'saved', which stays in scope forever. I think this is 
>> responsible for part (not all) of SushiNet's memory problem. I don't 
>> think the previous delegate should be saved at all - can't imagine 
>> what for.
>
>It is pushed onto a stack for when the delegate calls #answer...
>
>(I think this is why it is saved, I wonder if callcc will save it for
>you?  This could be a place where we leak.)

Yes, this is one place where we leak. callcc saves the local variables 
of all functions that are in the stack when callcc is called. So, the 
'saved' local variable gets wrapped in a continuation when we call 
'call' from 'delegate_to'. This is the reason we should not have this 
'feature'. However, there also seem to be other places where we leak, 
which I haven't found yet...

>> 3) A question is whether the delegate of a controller registered for 
>> backtracking should also be backtracked. In the current version of 
>> Borges, this isn't done (only the value of @delegate is stored in 
>> StateHolder),and I'm not doing it either; but I'm not yet sure which 
>> way is the proper way.
>
>If a controller has a delegate, it should be backtracked 
>appropriately,
>so you can #answer to the proper component on the delegate "stack".
>(The chain of calls to #delegate_to.)

#answer does not depend on backtracking. The component we have answer 
to always gets saved in the @continuation variable.

Vladimir Slepnev