Re: Visitor pattern vs if-ladder
Giovanni Azua wrote:
"Joshua Cranmer" <Pidgeot18@verizon.invalid> wrote in message
Several problems I see here:
1. You're not doing it right. If you're going to complain about the
visitor pattern being error-prone, the least you could do is to provide a
*correct* implementation.
I don't see any concrete problem here, only an empty claim.
You completely ignore the possibility of inheritance. So if I want to
visit Engine with a SoupedUpV8Engine, it will fail--no-op.
2. Speed? Reflection is very slow and prohibits any kind of optimization
whatsoever.
Old myths and cliche, another empty claim.
I did a simple microbenchmark. It finds that (avoiding the inlining of
the method call), the time it took to do a regular method call was
approximately 1% the time it took to do a simple reflection call. If I
made the method a no-op, that was cut in half, which leads me to believe
that my computer's granularity in nanoTime() is getting in the way.
In places where the tree is extremely large--say the parse tree of a
compiler--a 100-fold slowdown in dispatch can become noticeable.
3. Using reflection kills type safety, since you're essentially
prohibiting the compiler from figuring out what's going on. Another way of
putting it is that you've added dynamicism which pushes what should be
compile-time errors to runtime. Which is the wrong direction, in case you
didn't know.
An empty claim again. The IVisitor has a generic parameter that defines
exactly which type of Elements it can visit. If you try to pass a
mismatching argument you will get the acclaimed compilation error:
http://perfectjpattern.sourceforge.net/xref/org/perfectjpattern/core/api/behavioral/visitor/IVisitor.html
Suppose I accidentally omit to write the visit for an Engine. The
pattern will turn that call into a no-op--it won't even tell me at all.
In the traditional model, the compiler will most likely inform me that I
forgot to write the visit(Engine) method.
or you have a library that needs to be able to inspect running class
methods for various reasons.
I do, in order to implement the double-dispatch :]
And you can't even do the method lookup correctly.
I wouldn't consider this a valid case: you're trying to do the VM's job
for it instead.
Unlike you, I don't do this, I write unit tests that proof the code right,
up front.
You need to proofread your post....
Perhaps a taste of Dijkstra would help:
"Program testing can be used to show the presence of bugs, but never to
show their absence!"
But in any case, the purpose of my signature (in part, at least) is to
point out that code I present here is not necessarily bug-free and that
any analysis I present is more important than the actual code.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth