"Charles Comstock" <cc1 / cec.wustl.edu> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0405271127360.21935-100000 / earwig.int.cec.wustl.edu...

<snip/>

> If you don't check the superclass then the usefulness of the visitor
pattern
> drops significantly.  The whole idea is to be able to walk a hiearchy and
catch
> different classes at different levels.  I'm not trying to do multiple
dispatch,
> just double dispatch, so I only really need to walk the type hiearchy in
one
> dimension.  That's not great for efficiency, but it's not horrible either.

Completely true.

> The main problem with the proc based solution is I no longer can leverage
> inheritance on the visitor side, only on the visitee side.  In other words
I
> can't create a skeleton of a visitor and derive from it to add specific
> functionality, unless I implement my own system of inheritence of the
procs.
> Which is slow and bad, and not really a solution.

Well, you could change it from an implicit block argument to an explicit
method argument and then you can throw in anything that implements call().

> While I can understand it wouldn't work effectively for cases where you
were
> walking one hiearchy that was inside a module and one that was outside
with
> similar names, I think the solution I presented works fine for 90% of the
use
> cases.

Well, my code wasn't meant to be a replacement for yours.  I just wanted to
see how a quick hack of MD could look like.  I'm aware that these are
different pairs of shoes with differnt requirements.  Although, from an
abstract perspective Visitor is a special case of Double Dispatch which in
turn is a special case of Multiple Dispatch. :-)

Visitor has its merits but nevertheless I don't like it very much.  On one
hand you retrofit functionality to a class hierarchy but on the other hand
you need this class hierarchy's collaboration to make it happen if you use
visitor.  I find this a bit too intertwined.  I prefer the "hash lookup with
class" approach.  If you do that inside the visitor, you don't need the
visitee to call any visit_<klass> methods and your visitor code is
completely independend from the class hierarchy you want to visit.  It seems
to me to be a better separation of concerns.

If you view it as a way of adding methods to a class, then it's clear that
you will need it more seldom in Ruby than in compiled languages, because you
can dynamically add methods by either defining new methods in a class,
defining singleton methods or including modules.

Another interesting article on the matter:
http://www-106.ibm.com/developerworks/java/library/j-diag0115.html

You can find a lot other interesting stuff about the matter here:
http://www.google.com/search?q=%22visitor+pattern%22+site:ibm.com

Thanks for the nice and interesting discussion!

Kind regards

    robert