3 ms·
I agree. Let's imagine writing a compiler without the visitor pattern. In fact, hey, let's go a step further and build one in a functional language. I'd be will
by king_magic 12y ago
I agree. Let's imagine writing a compiler without the visitor pattern. In fact, hey, let's go a step further and build one in a functional language. I'd be willing to put money down that the strategy that would evolve for say, code generation, would look a hell of a lot like - wait for it - the visitor pattern.
To your point, OO & design patterns aren't necessarily intertwined.
- lmm 12y agoThe double-indirection of the visitor pattern is unnecessary in a language with pattern matching. I mean sure, it's just syntax, just sugar - but readability is important. As the saying goes, a design pattern is a structured way of working around a language deficiency.
- king_magic 12y agoI agree, but I'd argue that double-indirection isn't really a defining characteristic of the visitor pattern. In fact, I'd argue that the visitor pattern is really one of the most "functional" patterns there is.
- TillE 12y agoQuite. It should be obvious how to implement it using std::function and lambdas in C++, for example. Having a bunch of polymorphic classes is an ugly implementation detail, not the essence of the pattern.
- deleted 12y ago[deleted]
- j_jochem 12y agoFrom what they taught me at software engineering 101, double dispatch is exactly the point of the visitor pattern. If your instance of Visitor lacks double dispatch, that means it's just a very complicated way of performing external iteration on Composites.
- pacala 12y agoActually, the visitor pattern (in Java) is significantly harder to use than pattern matching. Visitors break variable scoping. You have to manually add a lot of classes and instance variables to get the equivalent behavior of a pattern matching tree. Then you have the pain of having to jump around N classes to track what the code is doing. You are better off by just adding an enum to each node and switch + cast.