VisualWorks
WebVelocity
Let's get philosophical for a moment. What is History? It's not the past, it's someones recollection of the past. So.. what is the execution stack. We like to think it's the history yeah? Well, what if you could rewrite it too?
You can! In Smalltalk at least (And C, but you'll be struggling in other languages to do it easily). Seaside does this with Continuations, but that's not the only place you'll find this whacky history-rewriting. You'll also find it in your friendly VW debugging simulator.
And, now you'll also find it in the package BeforeYouLeave that I've just published to public store. I had my mad scientist hat on last Friday when I was trying to solve a particular problem to do with inserting #ensure: like logic without having to wrap everything up in a block.
So what did I concoct? Well, basically, it inserts a method in to the execution stack such that when your method leaves, a block of code will run - even if the process terminates or an exception unwinds. In effect, it works like ensure: but at the 'Method' level instead of the block level. Or put another way - ensure: is used to empower the sender, BeforeYouLeave is used to empower the sent.
How do you use it? Actually it's stupidly easy:
thisContext onExitDo: [ my block of code to run when this method exits ]
The nice thing about this approach is that you can make your own protocols that use this, simply by calling it on different thisContext's - in fact, due to a good idea by Travis Griggs, you can also set up a block of code to run when a Process ends (or terminates).
Processor activeProcess onExitDo: [ my block of code to run when this process ends ]
So thanks to David Price, Travis Griggs and Terry Raymond for their input / help on this fun little goodie. It's in public store - so enjoy.
By James Robertson on December 11, 2006, 9:36:27 amComment by James Robertson
How is that different from what you can do with Method Wrappers?
By Levi on December 11, 2006, 11:28:39 amI prefer to think of the stack as the future of the program, not the past. The top of the stack is where the program execution goes after the current stack frame finishes executing and returns, and it only executes the part of the stack frame that hasn't executed yet. In fact, this interpretation essentially says that the stack represents the continuation of the program, which is why Seaside is able to do its thing.
The stack does contain some information about where the program has been, but it is very incomplete information (any frame that completely executed has been removed) and it's only a side-effect of storing the work that remains to be done.
This doesn't change the gist of your main point at all, but you're really fiddling with the future of the program rather than its past.
By Michael Lucas-Smith on December 11, 2006, 3:14:19 pmComment by Michael Lucas-Smith
Interesting take on things Levi - I like it. It's an odd future though, because we've already been there for the future to exist :) So I guess I'm altering the past and the future!
James: For what I'm doing, I want to be able to say "this method will do x, y z on exit" and I want it to say that in the method itself, not somewhere else invoking a method wrapper. Locality of context to what you're doing is important. When I first started this, I trued using a pragma that would wrap up the method in a method wrapper since that seemed the most logical way to achieve the desired result. In the end, that approach was fraught with difficulties and manipulating the stack turned out to be the blindingly obvious.