Continuations
December 23rd, 2004
... finally start to make sense. I've heard a lot of buzz about them, but only now I start to understand them a bit.
One question that remains: why store "what will follow" under some key, instead of storing "what has been" under a key? Wouldn't it be easier to claim "this page id means that this user has done that and that and that, and these request parameters indicate that he will now go there". The net effect will be the same, I think, but the abstraction wouldn't leak that much (to the programmer, that is).
Let's try to restate that: instead of changing objects in a session when receiving a HTTP request, you take a copy of those objects (leaving the originals as they were), and start working on the copy. You can do the same actions that you would normally perform on the original objects. There's only one difference: the original objects are now stored in a repository under a page-specific ID. When the user has cloned her window (or pressed the back button, or...), you can fetch those objects again (thus going back to the state she was), and continue from there. In my gutt feeling, this would reduce the amount of continuation-specific code (sendPageAndWait() - huh?), including the JavaScript-flow enabling dependency.
I think I have to re-read the article, seems like I have missed something. If you can explain me what I've missed, I will be very grateful.
April 21st, 2008 at 10:17 PM Not sure what you are implying, but your comment does seem to point out something you have _not_ grasped yet. The wording about 'what will follow' as opposed to 'what has been' is pretty much a matter of point of view, but however one that shows the difference in a very subtle way. The point is that the 'state' captured in a continuation is extended beyond the typical session state people would capture: it holds the local variables on the stack and the current position of the instruction pointer. To be explicit, this means continuations are (implicitely) remebering the outcome of passed if-tests, values of for-next-counters, etc etc Main advantages: - when people come back you don't have to re-establish that "position" in the flow from the state you manage in the session: it is instantly available. - as a programmer you don't have to think about not forgetting any pieces of the state to re-establish that position - you can easily modify your flow whithout needing to modify the state management (see this: http://blogs.cocoondev.org/mpo/archives/002445.html) As for leakage: the sendpageAndWait is just a convenience wrapper around actually creating the continuation... that is something I don't think we can avoid: the programmer will need to indicate at which points there is a wait-for-your-return-point to be created... Associating further down however, I do recognise one remark in you posting that is still fighting in my head as well: and that is how all this is mapped onto the