You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm really excited to see you take this project on. A faster Perl-Critic would be very useful to the community. However, you might want to consider a different approach...
The Perl::Critic::Policy modules have evolved over the years to handle many edge cases that appear in real-world Perl code. Some of them have become quite complex, and reproducing all that code by writing equivalent modules for Perl-Lint is a very big task. The Perl-Critic engine also has several optimizations that are not trivial to implement.
So instead, you could build a layer over Compiler::Lexer and Compiler::Parser that produces a DOM identical to PPI. That way, Perl::Critic (and everything else that uses PPI) can get the speed benefits without having to be re-written for an entirely new DOM. And the unit tests for PPI would be a perfect test suite for your implementation.
I'm not really familiar with Compiler::Lexer and Compiler::Parser, and they may have completely different goals from PPI. But I know Adam Kennedy put a lot of thought into designing the DOM for PPI and it has proven to be good enough for many purposes.
If it is feasible at all, I think generating a faster PPI-compatible DOM would be easier and more productive than rewriting all of Perl-Critic for a new DOM.
The text was updated successfully, but these errors were encountered:
That sounds nice idea, but I have the problem realistically; Compiler::Lexer is almost stable, but Compiler::Parser is not.
It is a thing that I know you have been carrying out this project, Compiler::Lexer can analyze the perl code practically (but it has some problems, so I sent issues). But Compiler::Parser can not parse most of the perl code and it occurs SEGV frequently.
So I think it is difficult to construct the PDOM (or compatible structure with it) by Compiler::Lexer and Compiler::Parser.
However, I think if this idea can realize, it is so nice. Therefore I think it is a good effort to implement the compatible constructor. But it is big job in any case, so I think that it is better to do it in another project.
I'm really excited to see you take this project on. A faster Perl-Critic would be very useful to the community. However, you might want to consider a different approach...
The Perl::Critic::Policy modules have evolved over the years to handle many edge cases that appear in real-world Perl code. Some of them have become quite complex, and reproducing all that code by writing equivalent modules for Perl-Lint is a very big task. The Perl-Critic engine also has several optimizations that are not trivial to implement.
So instead, you could build a layer over Compiler::Lexer and Compiler::Parser that produces a DOM identical to PPI. That way, Perl::Critic (and everything else that uses PPI) can get the speed benefits without having to be re-written for an entirely new DOM. And the unit tests for PPI would be a perfect test suite for your implementation.
I'm not really familiar with Compiler::Lexer and Compiler::Parser, and they may have completely different goals from PPI. But I know Adam Kennedy put a lot of thought into designing the DOM for PPI and it has proven to be good enough for many purposes.
If it is feasible at all, I think generating a faster PPI-compatible DOM would be easier and more productive than rewriting all of Perl-Critic for a new DOM.
The text was updated successfully, but these errors were encountered: