Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

cppcrypt.tumblr.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#31

Post by wbl »

Q6T46nT668w6i3m wrote: post #9
grandinj wrote: post #3

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.

I’ve never considered this, but I think it’s a fair assessment! It’s particularly striking when you see a compiler with multiple visitors that are refactored into one or two visitors to reduce the number of traversals. I think I understand the cause, it’s easier to start with a visitor pattern than refactoring into a visitor pattern. Nevertheless, for many problems, like compiler construction, I’ve never seen a patte…

Use the right language: one with ML style pattern matching.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#32

Post by barrkel »

moron4hire wrote: post #27
mcv wrote: post #16

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 comp…

It's not a "shortcoming" of the language per se . Visitor is a mitigation of the Expression Problem[0] on the Object Oriented spectrum. Object oriented designs need to use Visitor to add functionality to existing data structures, whereas doing such is a natural feature of Functional languages (though FP languages have their own awkward angle in attempting to add new data structures to existing functionality). This is…

It's a shortcoming of languages that don't have multiple dispatch.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#33

Post by divs1210 »

Q6T46nT668w6i3m wrote: post #9
grandinj wrote: post #3

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.

I’ve never considered this, but I think it’s a fair assessment! It’s particularly striking when you see a compiler with multiple visitors that are refactored into one or two visitors to reduce the number of traversals. I think I understand the cause, it’s easier to start with a visitor pattern than refactoring into a visitor pattern. Nevertheless, for many problems, like compiler construction, I’ve never seen a patte…

check out multi-methods and multiple-dispatch OO

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#34

Post by alexeiz »

AndrewGaspar wrote: post #5
Alterlife wrote: post #4

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

This would definitely be better as a blog post than a dog post.

> dog post

This kind of abomination even has a name.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#35

Post by scroot »

yvdriess wrote: post #21
mcv wrote: post #16

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 comp…

I've always heard that pattern itself is older than C++, originating from Smalltalk.

It does come from Smalltalk, which is in part why it looks so sloppy and strange in other languages (a Ruby example I saw even had an intermediary class for the visitor part, which doesn't really happen in Smalltalk).

The reason to use this pattern is to leverage real polymorphism. In Squeak/Pharo, the graphics system is called Morphic, which uses this pattern all the time to draw different kinds of objects to different kinds of Canvases. With a visitor pattern, each object can "know" how to draw itself to a given canvas.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#37

Post by [deleted] »

moron4hire wrote: post #27
mcv wrote: post #16

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 comp…

It's not a "shortcoming" of the language per se . Visitor is a mitigation of the Expression Problem[0] on the Object Oriented spectrum. Object oriented designs need to use Visitor to add functionality to existing data structures, whereas doing such is a natural feature of Functional languages (though FP languages have their own awkward angle in attempting to add new data structures to existing functionality). This is…

[deleted]

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#38

Post by geezerjay »

barrkel wrote: post #32
moron4hire wrote: post #27

Earlier quoted context omitted.

It's not a "shortcoming" of the language per se . Visitor is a mitigation of the Expression Problem[0] on the Object Oriented spectrum. Object oriented designs need to use Visitor to add functionality to existing data structures, whereas doing such is a natural feature of Functional languages (though FP languages have their own awkward angle in attempting to add new data structures to existing functionality). This is…

It's a shortcoming of languages that don't have multiple dispatch.

Why should anyone force changes into the core language if all you want to do is use an obscure programming construct in a corner case that's easily implemented with a design pattern?

Some of these complains are at best very misguided.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#39

Post by kazinator »

drmeister wrote: post #25

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. :-)

The visitor pattern doesn't disappear under CLOS, but all the framework boilerplate code does.

So that is to say, we can still have a situation where we have a tree of objects T with nodes N of different classes (expression, if-statement, ...) and visitor objects of different classses (pretty-printer, evaluator, ...).

Then given some generic function G and visitor object V, we walk the nodes of the tree, and simply (funcall G N V) for each node N that we encounter.

The remaining verbiage is then in all the method specializations we have to write for G for all the N V combinations that occur.

For all the framework brevity, we yet have an additional flexibility relative to the Visitor Pattern: namely, we can not only vary the choice of visitor object V, but also of G. The Visitor Pattern fixes the generic function in terms of some hard-coded some visit()/accept() protocol.

Post reply on HN