PPI.pm is the new, shiny and soon-to-be-released (heading into beta now) pure-perl perl parser. It is Parse::Perl at long last. It's also my baby.
Because it is able to parse perl without executing, and without needing to see anything outside of the one file or string of code, it removes all the previous problems with "parsing" perl source code, and the subsequent risk of corruption or security issues, and so it is also quite likely to end up as the pillar on which a whole new generation of perl tools will stand.
This will include things like CPANXR, the CPAN Cross Reference, Perl::Backport, a variety of diff-related tools, structural analysis and code metrics tools, and (hopefully) refactoring tools like a perl equivalent of the IntelliJ IDEA editor.
Now the problem with multi-API situations is likely to be that under normal situations, if some PPI-based software encounters Apache::Something->method it would normally interpret it as a method call in the "most current" version of the Apache::Something API.
The only alternative to this (for things like code editors) might be to check the API of the version currently installed on disk, but again this won't apply for things that work with CPAN as a whole, such as CPANXR.
Because PPI is purely syntax-based, and parses in a way that completely ignores the perl environment, it will have no idea if Apache::Foo->bar is meant for the new "current" API or the old "current" API.
If I had to speculate as how to make it handle it, it might mean the addition of some sort of hacky workaround that is mod_perl-specific or an Apache-specific version of PPI... and we are back in "workaround hell" again.
In fact, you wouldn't have to modify PPI itself, as the syntax is still valid, but it would mean adding mod_perl-specific stuff to everything built on top of PPI that needs to "resolve" a class or method.
This example is the one I had foremost in my mind earlier when I was talking about the problem with workarounds, where you have to keep adding more and more as you encounter additional things you hadn't predicted in advance. (and in this case didn't exist until a year ago).
But I'm sure there are others that I haven't yet thought of.
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
