Re: [Eli-project-users] Structural unparsing (Java)

[Peter P. <pe...@up...>]

Am 08.03.2011 16:50, schrieb W. M. Waite:
>
> I don't agree with the "simpler/clearer/cleaner" on this change.  I don't
> find a heavily overloaded procedure name "clearer" when I'm looking at the
> code and have to remember which of the n versions of that procedure I'm
> calling.  Either approach ends up with the same number of procedures, the
> same number of lines, and the same complexity.  In my opinion, clarity
> suffers when the name is generic.  A final (trivial) point is that the
> description of the Visitor design pattern in the GOF book does NOT rely on
> overloaded functions.  Making this change thus reduces the transparency for
> someone trying to compare the implementation to that description.
>

I must admit that I didn't know that the GoF used differently named 
visit() functions. Nowadays you usually see the overloaded version using 
only a single method name, e.g. in

http://en.wikipedia.org/wiki/Visitor_pattern

or

http://www.cs.ucla.edu/~palsberg/paper/compsac98.pdf

Looking at the original GoF book you find the following footnode

"We could use function overloading to give these operations the same 
simple name, like 'Visit', since the operations are already 
differentiated by the parameter they're passed. There are pros and cons 
to such overloading. On the one hand it reinforces the fact that each 
operation involves the same analysis, albeit on a different argument. On 
the other hand, that might make what's going on at the call site less 
obvious to someone reading the code. It really boils down to whether you 
believe function overloading is good or not."


I don't think the human reader seeing

public void accept(Visitor v) {
     v.visit(this);
}

in a class implementing a certain node type
has to worry which visit method is called: It will be the one which is 
responsible for this node type.