Re: Visitor Pattern in Ruby

"Charles Comstock" <[e-mail]> schrieb im Newsbeitrag
news:[e-mail]...
> On Thu, 27 May 2004, Robert Klemme wrote:
>
> > 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.
> >
>
> It was designed as far as I can tell for use with compilers, that is where
it
> mostly frequently appears.  In that case I think it does a very good job
as you
> have a number of passes you need to perform across your AST which
hopefully is
> well structured into a nice class hiearchy.  That way you can generate
code for
> a AddOp, a BinaryComputeIsh, or some such hiearchy like that, catching
what you
> need where.  An AST is something that is well suited to a very deep class
> hiearchy and so the Visitor excels at processing it.  As for other
applications,
> I'm not sure if it's as effective there.

And, as a programming language is usually quite fixed and does not change
often, visitor's problems with changing class hierarchies don't show up
here.  Plus if there are only relatively few passes, then there is not much
to change if the AST class hierarchy gets extended.

> > 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.
> >
>
> Right, I'm aware of that.  Actually it is interesting that C# has
something akin
> to open class definitions to facilitate generated code.  I haven't checked
to
> see if all file need to be present for the compile phase or if it can add
> additional functionality later, would be interesting to see.

If you learn anything further about this C# feature, please let us know.  We
just have to make sure there is something we can learn for Ruby in order to
not get too far off topic. :-)

> However when you can do that alot of the code winds up looking more like
chain
> of responsability then Visitor.  Oh well I guess a number of the patterns
are
> all dependent on how you view them.

This happens to me all the time: a lot of those patterns look quite similar.
I guess that's because they use the same principles underneath.  The most
important point seems to be to me, how tasks are delegated from one object
to other objects.  But it's always about delegation.  Interestingly enough,
things don't get easier for us when we look at them from such a broad
perspective.  With some simple basic priciples very complex systems can be
built...

> > Thanks for the nice and interesting discussion!
> >
>
> No no, thank you :)

You're welcome.  We got to keep the NG attractive, to pull more and more
people over from ruby-talk. :-)

Regards

    robert