3 ms·
Actually, after reading the walk.go code I still wonder what the best way to do it would be. (Not saying it's bad now, though I'll still remain my devils advoca
by cube2222 10y ago
Actually, after reading the walk.go code I still wonder what the best way to do it would be. (Not saying it's bad now, though I'll still remain my devils advocate)
As I skimmed through the code, in my opinion you could easily have a Walk(v Visitor) method on each of those node types.
This way you'd have no need for casting, and in the Walk method you would be able to use type-specific functionality without the need to cast. The only disadvantage I see is that the Walking functionality would be spread out among the code in different places, but this isn't a problem with modern editors.
I'll note this down somewhere and if I have time I'll test it out sometime.
- pbnjay 10y agoGreat minds think alike (IMHO) https://www.reddit.com/r/golang/comments/60dik1/a_utility_for_running_exhaustiveness_checks_on/df669jk/ https://www.reddit.com/r/golang/comments/60dik1/a_utility_fo...
- cube2222 10y agoAnyways, my conclusion is. In most cases it IS an anti-pattern. Only if the, let's say "observing" function (the one that decides on the type), is really just observing the behavior nad trying not to interwind with the mechanics of the actual structures is it justified I think. In that case it provides greater cleanliness of your code. In this case though, as this is the ast package, and walking is a standard functionality of an ast, I think this could just as well be implemented with interfaces.