So, I have Devel::Refactor doing extract_method, and I even have the beginnings of an emacs based browser (though for reasons that I still don't understand, it only works once per package per emacs session, time to go digging into EPL methinks) and I'm starting to think about what it needs to assume as before and after conditions.
At the very least, the code must compile cleanly both before and after any refactoring, and must allow for rolling back changes if the post conditions fail. Right now there's very little state kept in the refactoring engine, but I think that's going to change (or it'll be impossible to check that compilation succeeds after the refactoring.)
And it's got to deal with modules that contain multiple packages (I had hoped to use Schwern's Module::Info, but it doesn't do that part yet... shame.)
And...
And...
That everyone is suddenly wanting to reinvent the module info/module tools wheel when Tom's pmtools were something Jarkko wanted to add to the core yet noone seemed interested in polishing up....
Re:I find it interesting
pdcawley on 2001-11-26T09:14:47
Well, having looked at pmtools that's mostly because what pmtools doesn't do anything that I need. At the very least I need object orientation. I want to be able to do:
$module->insert_method($method_object)
Or maybe:
$class->insert_method($method_object)
Where $class is one of the classes defined in a module. Tom's stuff is okay as far as it goes, but it doesn't go nearly far enough.
Re:packages_inside
pdcawley on 2001-11-26T16:41:15
Ooh, coolness. I spy at the very least a parent class...
