Multi-API Incompatible with PPI

[Adam Kennedy <ad...@phase-n.com>]

Now I'm back up and running again, here an additional item for the 
namespace debate I didn't have the chance to cover properly earlier.

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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Multi-API Incompatible with PPI

[Adam Kennedy <ad...@phase-n.com>]

Yep, they would.

Unless the structural indexer was capable of understanding that...

But in general, yes.

Adam

Eric Cholet wrote:
> Le 9 janv. 05, à 13:14, Adam Kennedy a écrit :
> 
> [...]
> 
>> 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.
> 
> 
> Who knows, maybe I've done
> 
>   *Apache::Something::method = sub { ... };
> 
> and then all bets are off, modperl or no modperl.
> 
> -- 
> Eric Cholet

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Multi-API Incompatible with PPI

[Eric Cholet <ch...@logilune.com>]

Le 9 janv. 05, à 13:14, Adam Kennedy a écrit :

[...]
> 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.

Who knows, maybe I've done

   *Apache::Something::method = sub { ... };

and then all bets are off, modperl or no modperl.

--
Eric Cholet


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org