Visitor pattern and separating iteration

[Karsten Wutzke]

On 22 Jul., 22:25, Ian <hobso... at gmaiil.com> wrote:
> Hi Karsten,
>
> On 22/07/2010 12:03, Karsten Wutzke wrote:> What is it I'm missing?
>
> I think you are making it more complicated than it really is.
>
> The visitor pattern is about bringing all the little bits that would
> otherwise be scattered all over
> many node classes into one visitor class. For code generation this means
> that all the code generation is done
> in your visitor class. For pretty-printing you have another visitor
> class. For code optimization a third
> visitor class.
>
> If there is only one sequence in which the nodes should be visited, then
> you can build it
> in to the nodes of the tree.
>
> If you need to visit your nodes in different orders you might be better
> off building a separated
> tree-walker class for each order. Thus you might have a
> post-order-walker for use with the code
> generating visitor, and a in-order-walker for a pretty-printing visitor.
>
> The optimizing walker may need to take different routes through the tree
> depending
> upon what it finds. For example, it may compute the value of the RHS of
> an assignment
> before computing the address of the LHS, so it can make better use of
> registers. Here the
> visitor class itself needs to do the walking.
>
> Regards
>
> Ian

My objects to iterate over are plain object-structures, composites. I
have only one code generation pass, so generating code and then pretty
printing is not intended/possible. I have many user options to
configure the code generation. The visitor pattern is ideal for that
matter, because I can keep the options in the generator rather than
scatter all the options into the object classes' accessor methods.
(making me think the visitor is just right and not more complicated
than needed)

I was just curious about separating the iteration code into the object
classes, because GoF said "The main reason to put the traversal
strategy in the visitor is to implement a *particular complex*
traversal, one that depends on the results of the operations on the
object structure." My code generator isn't really THAT complex (I
thought), but reviewing the latter part of the quote makes me believe
I was wrong. Code generation always depends on the previous results,
that is the children of a composite in the object structure. Now that
I realized it, I feel great about traversing in the visitor.

Python just has a few consequences that makes creating common
interfaces/abstract classes a little unusual. I'm just starting to
really love Python (or its API), though I don't feel I've already
discovered the core what it is really about.

Best regards
Karsten