4 ms·

OK I might be wrong about the visitor pattern, but what I really did not like is to use the accept() and visitBlah() way to execute AST nodes: https://craftingi

OK I might be wrong about the visitor pattern, but what I really did not like is to use the accept() and visitBlah() way to execute AST nodes: https://craftinginterpreters.com/representing-code.html#the-visitor-pattern https://craftinginterpreters.com/representing-code.html#the-... I did continue reading the book (not the original author of that reply) but I do think it is distracting for newbies. I had to come back to this page over and over again to recollect memory about the pattern, because I usually read it one chapter or a few sections every week, so every time I had to remind myself how this visitBlah() and accept() pair works. I really think a big switch() (or anything that works but is simpler) would be a lot easier to understand. The other reason I dislike this kind of stuffs is that I have someone in the team who really likes to use patterns for every piece of code. It's kinda difficult to tell whether it is over-engineering or not, but my principle is that intuition always beats less lines of code (or DRY), unless it is absurdly more lines of code or repetition. And to test that principle you just grab a newbie and see which one makes more sense to him.

almostgotcaught 1y ago
> I really think a big switch() (or anything that works but is simpler) would be a lot easier to understand. It's much easier conceptually to implement this using recursion instead of a while loop and a token stack (it's basically DFS). So I disagree with you there. > The other reason I dislike this kind of stuffs is that I have someone in the team who really likes to use patterns for every piece of code. It's kinda difficult to tell whether it is over-engineering or not, but my principle is that intuition always beats less lines of code (or DRY), unless it is absurdly more lines of code or repetition. And to test that principle you just grab a newbie and see which one makes more sense to him I'm with you - I really don't give a shit about patterns (which was my whole original point - who cares). But that last part I don't agree with - systems code (like a parser) doesn't need to be legible to a noob. Of course we're talking about a textbook so your probably right but like I said most production parsers and AST traversals are written exactly this same way. So anyone learning this stuff hoping to get a job doing it should just get used to it.
mrkeen 1y ago
Nope, you had it right. Visitor thoroughly confuses me in the context of parsing (maybe in all contexts.) visit and accept are not the verbs I want to be seeing in the code. I want to see then, or, and try.
- almostgotcaught 1y ago
  Parsers "accept" or "reject" programs. It's completely standard language.
  - mrkeen 1y ago
    Alright, so where can I read more about the visitor pattern's "reject" method?
    - almostgotcaught 1y ago
      > all other tokens should flag an error Ie the link I posted above
jpc0 1y ago
> so every time I had to remind myself how this visitBlah() and accept() pair works. I really think a big switch()… This is just and alternative implementation of the visitor pattern. Whether you implement it using dynamic dispatch or a switch or an if stack its all the same pattern…

almostgotcaught 1y ago

> I really think a big switch() (or anything that works but is simpler) would be a lot easier to understand. It's much easier conceptually to implement this using recursion instead of a while loop and a token stack (it's basically DFS). So I disagree with you there. > The other reason I dislike this kind of stuffs is that I have someone in the team who really likes to use patterns for every piece of code. It's kinda difficult to tell whether it is over-engineering or not, but my principle is that intuition always beats less lines of code (or DRY), unless it is absurdly more lines of code or repetition. And to test that principle you just grab a newbie and see which one makes more sense to him I'm with you - I really don't give a shit about patterns (which was my whole original point - who cares). But that last part I don't agree with - systems code (like a parser) doesn't need to be legible to a noob. Of course we're talking about a textbook so your probably right but like I said most production parsers and AST traversals are written exactly this same way. So anyone learning this stuff hoping to get a job doing it should just get used to it.

mrkeen 1y ago

Nope, you had it right. Visitor thoroughly confuses me in the context of parsing (maybe in all contexts.) visit and accept are not the verbs I want to be seeing in the code. I want to see then, or, and try.

almostgotcaught 1y ago
Parsers "accept" or "reject" programs. It's completely standard language.
- mrkeen 1y ago
  Alright, so where can I read more about the visitor pattern's "reject" method?
  - almostgotcaught 1y ago
    > all other tokens should flag an error Ie the link I posted above

jpc0 1y ago

> so every time I had to remind myself how this visitBlah() and accept() pair works. I really think a big switch()… This is just and alternative implementation of the visitor pattern. Whether you implement it using dynamic dispatch or a switch or an if stack its all the same pattern…