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.
self doSomethingWith: aFile.
aFile openDuring: [self doSomethingWith: aFile].
The implementation of File>>openDuring would look something like this:
For more, see:
Some comments on how it can be used in languages that lack DeterministicFinalization
would also be neat.
public void setUp();
public void thunk( void );
public void tearDown();
static public void execute( Thunk thunk )
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))
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)
will do. This, of course, expands into
(let ((file (open path...)))
(unwind-protect (grovel-over-file 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