Execute Around Method

When a pair of actions have to be taken together (such as file open/close), you can use a HigherOrderFunction that wraps the actions around the function that is passed in.

Instead of:

 aFile open.
 self doSomethingWith: aFile.
 aFile close.

We have:

 aFile openDuring: [self doSomethingWith: aFile].

The implementation of File>>openDuring would look something like this:

 File>>openDuring: aBlock
  self open.
  aBlock value.
  self close.

For more, see:

Some comments on how it can be used in languages that lack DeterministicFinalization would also be neat.

 interface Thunk
 {
public void setUp();
public void thunk( void );
public void tearDown();
 }

 class Transaction
 {
static public void execute( Thunk thunk )
{
 thunk.setUp();
 thunk.thunk();
 thunk.tearDown();
}
 }

Basically, a hack around poor resource management schemes. I don't want to ever, ever again have to balance open()s and close()s throughout an application, yet in some languages you have to do this explicitly. Some day, maybe the world will move past C.

This describes rather a lack of unwind-protect functionality than a need for an around method. If you use a Real Object System(tm) you can do stuff like this

(defmethod thunk :around ((t thunk))

  (setup t)
  (call-next-method)
  (tear-down t))

Not sure you need the full power of the :around stuff in the Real Object System (TM), I think a simple

(with-open-file (file path :direction :input)
(grovel-over-file file))

will do. This, of course, expands into

(let ((file (open path...)))
(unwind-protect (grovel-over-file file)
(close file)))

I agree completely that the lack of an UNWIND-PROTECT form in any language is a horrific lack---I'd go so far as to say that it makes it almost impossible to write robust programs. (Note that this pattern has been discussed under ResourceAcquisitionIsInitialization. In C++, this is faked with destructors, which C++ programmers who have not seen other languages somehow think this is a natural idiom. Ugh. -- AlainPicard

Well, there's no accounting for taste. I've seen other languages, and I do think C++'s "objects' destructors are guaranteed to be called when they go out of scope" pattern is more natural than any sort of low-level UnwindingTheStack paradigm. C++ is not my favorite language, but I think this is one thing that Stroustrup did right. -- KrisJohnson