Below are various signs that developers successfully use 
traversals and visitors in their work. Several of them refer to the Visitor
pattern from GOF (Gamma et al. book on Design Patterns).

The Visitor pattern allows you to name and reuse traversals and
to specify the visitors.

The Visitor pattern and its many variants has the disadvantage 
that the programs don't adapt to changes in the inheritance and part-of
hierarchies. Only the AP approach with succinct traversal
specifications provides increased flexibility.
(for further discussion, see the SIGSOFT '96 paper:
http://www.ccs.neu.edu/research/demeter/biblio/context.html).

Here is a table highlighting the benefits of AP with respect
to the Visitor Pattern:

			 without AP		with AP
-----------------------------------------------------------------------
add an accidental class  change each visitor    visitor unchanged
                         change traversal code  no change to traversal spec.	

add an essential class   change each visitor    change some visitors 
                         change traversal code  small change to traversal spec.	

traversal		 not structure-shy	structure-shy

visitors		 not selective		selective



If programmed directly in Java or C++, visitors and traversals can
be implemented in many different ways. Some possibilities are:

1. GOF Visitor pattern implementation: Requires a visitor method
   for each class in the traversed class graph. Allows to reuse
   same traversal several times with different visitor classes which
   are all subclasses of the same visitor class.

2. Demeter/C++ approach described in the AP book.

3. Demeter/Java approach.

4. Approaches described in the literature below.

==========================
John Vlissides has addressed the 
Visitor pattern in his Pattern Hatching column
in the C++ report (SIGS Publications). The two relevant articles are:

1. The Trouble with Observer: September 1996

2. Visiting Rights: September 1995
==========================
The PLOP '96 conference contains several 
Visitor-related papers.

From patterns-discussion-request@cs.uiuc.edu Fri Jun 28 15:23:03 1996
From: Ron Lusk 
Subject: RE: when are manager (mediator) patterns appropriate?
Date: Fri, 28 Jun 1996 14:46:18 -0400

> It sounds to me like the GOF Visitor pattern might be
> useful in building some (clearly not all) of the "Manager"
> objects that need to manipulate the database.

I just ended my work on a project where the database-flavored objects 
were in a Composite, and were coupled enough to the application that 
Composite objects would detect events in their containers and respond 
appropriately. The responses, however, were embodied in Visitors which 
would traverse the appropriate levels of the Composite and update the 
database/check constraints/determine data completeness/etc.

At the beginning of the project, my lead developer was saying, "I don't 
know why we need all these Visitor things; it just makes things 
complicated." By the end, I'd overhear him telling our project leader 
(my client), "Sure, we can do that; I'll just fire off a Visitor when 
[some event] occurs, and the Visitor will implement that policy.  I'll 
have it for you this afternoon."

BTW, *my* design goal for the project was to use all the GOF patterns; I 
missed that goal by four patterns, so I hope to get called back for 
release 2.  ;^)

===============================