New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Remove direction from declarationVisitor #13
Comments
If you take away |
Yeah, a few of the rules I wrote also use it, but you could do it without. I think having a withDeclarationExitVisitor and equivalent expression visitor makes sense. Considering how often the exit visitors are used (not that much), this would make the visitors simpler and the rules run a bit faster. The only drawback is that the code for enter and exit, which are related, would be more separated in terms of lines of code than what they are today. But I think this would be nice for the next major version 👍 |
What I liked about using Having the (same) code split between entering the next node and a final visitor sounds like a step backward to me - it would introduce 3 states too: 1 where you've not visited anything yet, 2 where you have, and 3 being after the last node. So, I'm glad you like the idea of exit visitors. |
That's a very good point 👍 |
Implemented in v2.2.0 https://github.com/jfmengels/elm-review/releases/tag/2.2.0 :) |
Both declaration and expression visitors are visited twice
This is quite useful to know in which "context" you are: Am I inside a let..in expression, which function declaration am I, etc?
For
let..in
expression, this can be quite useful, as the direction-less alternative can be quite painful to write.For declaration visitors though, the point of the "exit" visitor is, most often as I have seen, to remove the "current" function related information that were set in the "enter" visitor. But these will be overridden anyway by the next "enter" visit.
We might avoid a lot of visits by making the declaration visitor "direction-less", thus gaining in performance.
This will likely happen, unless scenarios are found where this simplifies the visit of a module drastically. If you know of any, please write them down as comments.
The text was updated successfully, but these errors were encountered: