←back to thread

1087 points smartmic | 1 comments | | HN request time: 0.203s | source
Show context
12_throw_away ◴[] No.44303909[source]
This has by far the best discussion of the visitor pattern I've yet to come across.
replies(3): >>44304154 #>>44304309 #>>44304662 #
dgb23 ◴[] No.44304309[source]
I don't work in typical OO codebases, so I wasn't aware of what the visitor pattern even is. But there's an _excellent_ book about building an interpreter (and vm) "crafting interpreters". It has a section where it uses the visitor pattern.

https://craftinginterpreters.com/representing-code.html#the-...

I remember reading through it and not understanding why it had to be this complicated and then just used a tagged union instead.

Maybe I'm too stupid for OO. But I think that's kind of the point of the grug article as well. Why burden ourselves with indirection and complexity when there's a more straight forward way?

replies(6): >>44304428 #>>44304648 #>>44304698 #>>44304986 #>>44306960 #>>44316589 #
12_throw_away ◴[] No.44304698[source]
As far as I understand it, the limited circumstances when you absolutely need the visitor pattern are when you have type erasure, i.e., can't use a tagged union or its equivalent? In that case visitors are AIUI a very clever trick to use vtables or whatever to get back to your concrete types! but ... clever tricks make grug angry.
replies(1): >>44305249 #
1. zem ◴[] No.44305249[source]
even when you have tagged unions, visitors are a useful way to abstract a heterogenous tree traversal from code that processes specific nodes in the tree. e.g. if you have an ast with an `if` node and subnodes `condition`, `if_body`, and `else_body` you could either have the `if node == "if" then call f(subnode) for subnode in [node.condition, node.if_body, node.else_body]` and repeat that for every function `f` that walks the tree, or define a visitor that takes `f` as an argument and keep the knowledge of which subnodes every node has in a single place.