by grandinj on 3/6/19, 2:23 PM
The thing that annoys me most about this pattern is that people always miss the "there needs to be lots of things you want to perform on those thingies".
And so we end up with a huge pile of visitor code, and there is one or maybe two actual visitors.
When it would have been far easier to read and modify if it was just coded out normally.
by Alterlife on 3/6/19, 2:31 PM
If you're like me and couldn't get past the first few slides because it's a terrible reading experience, go to the archive, which shows the whole thing in thumbnails. It makes it little better, even though the thumbnails are in reverse:
https://cppcrypt.tumblr.com/archive
by hathawsh on 3/6/19, 4:05 PM
The visitor pattern isn't appropriate everywhere, but it's quite good for traversing and manipulating ASTs (abstract syntax trees). An AST typically has many kinds of nodes, but programs that traverse the AST usually only care about some small subset of those nodes. The visitor pattern provides a clean solution: a generic AST traversal library visits all nodes in the tree while allowing the program to customize what happens when visiting specific nodes. I've found the visitor pattern very effective for creating derivative ASTs without knowing about everything that might be in the AST.
by drmeister on 3/6/19, 4:28 PM
It's things like the visitor pattern that led me to implement Clasp - a Common Lisp that interoperates with C++ and uses llvm as the backend (github.com/clasp-developers/clasp.git).
Common Lisp has generic functions and multiple dispatch - so it doesn't need the wretched visitor pattern.
Try writing a compiler using the visitor pattern - I dare you. :-)
by mcv on 3/6/19, 3:29 PM
This... I can actually see the point in this. The Visitor pattern is one of those patterns I never really saw the point of, and which mostly struck me as an over-engineered hack about a shortcoming in a language.
This example actually makes clear why you'd need to do it this was in C++ at least. Not sure which other languages would need this. It's certainly not pretty. Then again, dispatching twice is not so bad compared to your average Java-style over-engineering.
by laythea on 3/6/19, 6:19 PM
I clicked the link and then tumblr asked me about privacy, with a link to "Manage options".
I clicked the link, hoping to disable x,y,z and there is just text. No options!
Not reading further.
by slacka on 3/6/19, 6:25 PM
What a terrible UI on that website. Constantly clicking "Next"! Yuk. And every page required zooming in and out to make it fit on my screen. For a tech focused comic, you'd think the author could run it through an ImageMagick batch resize job. Bonus points for allowing keyboard back and forth navigation.
by doctorRetro on 3/6/19, 5:41 PM
While I, as a rule, try not to stand against good storytelling, I clicked far too many times while thinking "get to the point" before I just closed the tab.
by rgoulter on 3/6/19, 3:04 PM
by choeger on 3/6/19, 10:13 PM
The thing with the visitor pattern is that it indeed is useful for many operations over fixed data. But the same holds for simple pattern matching. Inheritance (or rather subtyping) is useful for changing data but a fixed set of operations. But what the eff do we do when we have many operations on changing data? The expression problem still is an interesting problem, because a data structure that solves it would basically be the "gold standard".
by deckar01 on 3/6/19, 3:07 PM
I don't understand why the class instance needs to accept the interaction. Why not just invoke the interaction directly?
interactor_p->interact(thingy_p)
Would this still be considered the visitor pattern or is the extra layer of indirection important?
by adgasf on 3/6/19, 2:59 PM
C++ match expressions would make std::variant a really nice alternative.
I assume there is already a proposal out?
by zwieback on 3/6/19, 6:11 PM
When I originally read about Visitor in the GoF book it was fun to work through its convoluted way but seemed ugly in any language, including the original SmallTalk.
I'd probably just do type checks and maybe use a 2D table for the possible interactions.
by dysoco on 3/7/19, 2:23 AM
I enjoyed the format of this, kept me interested. Nowadays I feel like if I read a blog post I have such a short attention span I'd just glance over it.
Would love to see more stories.
by ryanmarsh on 3/6/19, 6:05 PM
The only time I have ever encountered a code base where the visitor pattern was necessary and fulfilling its purpose is Babel (the JS compiler).
by malka on 3/6/19, 2:21 PM
their GDPR compliance screen is full of anti patterns. Will not read.
by satellitec4t on 3/6/19, 6:46 PM
How the &$#! do I read this
by jstimpfle on 3/6/19, 4:54 PM
If you ask me, the actual problem is the tree data structure... Maybe post order forms lend themselves better to processing.
The even deeper problem is what ASTs are meant to represent, to which the answer would be "possibly a lot of diverse things". Diversity is never good in a computational context. But I don't see a good way to avoid it in the context of programming languages and ASTs. The reason for the diversity is that programming languages should allow humans to specify what should happen in very few keystrokes.