Skip to content
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

Just A Suggestion #23

Open
thaljef opened this issue Jun 11, 2014 · 1 comment
Open

Just A Suggestion #23

thaljef opened this issue Jun 11, 2014 · 1 comment

Comments

@thaljef
Copy link

thaljef commented Jun 11, 2014

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.

@thaljef thaljef changed the title Just a suggestion Just A Suggestion Jun 11, 2014
@moznion
Copy link
Owner

moznion commented Jun 18, 2014

Thank you for your suggestion.

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.

How do you feel?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants