Re: Visitor pattern

> And yes, it's going to be a ginormous case statement anyway. I'd much rather 
> use polymorphism than case statements any day.

I am experimenting with these topics in Ruby as well. I have a pattern 
matcher on the trees that are output from my parser[1], but I find that 
to be the wrong place to put the kind of thing in that would normally be 
in a visitor.

I currently use that pattern matcher to construct a more stable AST, and 
then I am using the visitor pattern for the very much unfinished second 
part of that project[2]. The case statement is easily avoided by doing 
dynamic dispatch based on the (class) name of the node. The way I see it 
(currently) is that the node class is responsible for data manipulation 
(identifier lookups, etc...) and the visitor acts on the data.

Dynamic dispatch mentioned above would look something like this:

def accept(visitor)
   visitor.send( "visit_#{class.name.underscore}", self )
end

The big advantage of visitors in compiler/interpreter construction is 
IMHO that the code relating to one topic is bundled in a single class. 
Very often that code will relate to one level of abstraction. Having it 
together is just neat.

Note that the dynamic dispatch (one of) the disadvantage of the visitor 
pattern go away, namely that it is hard to add more nodes.

But maybe pattern matching would still be right on the level of the 
constructed AST? I will have to consider that idea strongly.

(Maybe one of you wants to comment on the code at [1]?)

cheers,
kaspar

[1] http://github.com/kschiess/parslet
[2] http://github.com/kschiess/rooc