So after dealing with Perl::Squish and associated problems, I'm wondering briefly this afternoon how the hell I'm going to get PPI::Transform, the API from hell, done any time before the 1.000 release I want to do for OSCON.
PPI::Transform is meant to be the API for writing classes and objects that munge PPI::Documents, in a way that is usefully like File::Find::Rule enough to allow for passing transforms around, combining them together, and doing other neato things.
And it's a bitch. I've written and thrown it away no less than 6!!! times.
So this afternoon it occurs to me that Perl::Squish has sort of the right approach to this.
http://ali.as/CPAN/Squish.html>
But that approach is not going to be able to do things like this.
$Transform->apply( $SomeObject )
Buuuuut... with a working $Transform->document($Document) command, all we'd need to do is get some random object to be a PPI::Document and then back again.
So 3 hours of hacking up a PPI::Transform ->apply registration system, we now have a shiny new PPI::Transform API.
What's really great about this is how adaptable it should be.
For example, imagine an editor that you could register your own transform command for.
"Clean up Whitespace" --> "Perl::Cleanwhitespace"
Perl::Cleanwhitespace would be a PPI::Transform subclass. The editor only has to create a default Perl::Cleanwhitespace object, and then pass a reference to SCALAR to it containing the contents of the currently open document, and everything will happen magically!
THIS means that you should now be able to write your own transform classes VERY easily, and they will be compatible with ANY editor that knows how to talk to the PPI::Transform API.
I look forward to writing my own transform classes I can move from editor to editor :)
Yeah baby!
Re:Many Perl documents?
Alias on 2005-07-04T03:17:14
I imagine that we'll end up with a number of indexers relatively quickly.
There is likely to be a number of things that need them.
