Lars has answered a question from Germany on around methods.

His answer is of general interest.

See http://www.ccs.neu.edu/home/lth/aao/impl.html

for a working paper on using around methods for exception handling.

-- Karl
--------------------------

From lth@ccs.neu.edu Tue Feb 25 15:50:43 1997
To: mira@informatik.uni-siegen.de
cc: lth@ccs.neu.edu, Karl Lieberherr <lieber@ccs.neu.edu>
Subject: Re: around methods 
From: Lars Thomas Hansen <lth@ccs.neu.edu>

>	Hi Karl,
>
>	I was trying to understand the around methods, but I must admit
>	that I am having hard time with them. It is not
>	clear for me, e.g.
>
>	        - what is the (intuitive) idea behind an
>	          around method, i.e. what is the motivation
>	          for introducing them?,
>	        - or what is the subtraversal's responsibility
>	        - what does the apply() method?
>
>

The intuitive idea is increased generality: the around method allows you
to surround a traversal below any node with arbitrary computation (which
may retain state), to do the traversal multiple times, and to not do the
traversal at all.

The subtraversal simply performs the traversal below the node (this is
no different from how it would "normally" be), and is packaged up in an
object that is passed to the around method with the name 'subtraversal'.
The apply() method on that object performs the subtraversal.  Perhaps an
example is in order: if you have a traversal+visitor pair:

The .cd:

	A = B.
	B = C.

The .beh:

	A { traversal t( V v ) { to C; } };

	V { before B (@ foo; @)
	    after B (@ bar; @)
	}

Then you can rewrite the .beh like this:

	A { traversal t( V v ) { to C; } };

	V { around B (@ 
		foo;
		subtraversal.apply();
		bar;
	    @)
	}

which is equivalent (in this case; the general case is a little more
complicated).  

Notice how there can now be local variables in the around method for
state retained around the subtraversal; in the original code, this state
would have to be in V so that the before and after methods could share
it, but even that would have been less powerful because the local state
in an around method is local to the method, i.e., in a traversal along a
graph that has multiple B's on it, each around method has its own copy.

The original motivation for around methods was exception handling, because
exception handlers need to be wrapped around the subtraversal starting at 
some class:

	V { around B (@
		try {
		  subtraversal.apply();
		}
		catch (MyException E) {
		  ...
		}
	    @)
	}

However, as Karl outlined and as I mentioned above, they are more generally
useful than just for exception handling.

The cost of around methods comes as a decrease in the amount of information
about the program that can be determined at compile (expansion) time.

Hope that helps; feel free to ask if you have other questions.

--lars