Re^2: Features missing in perl IDEs?

[BUU]

For my own edification, would you mind elaborating on what you consider to be "decent refactoring support"? What exactly is it? How would you use it?

[BrowserUk]

I wondered the same thing and found these.

[adrianh]

For my own edification, would you mind elaborating on what you consider to be "decent refactoring support"? What exactly is it? How would you use it?

What I mean by refactoring support is the ability to do safe automated refactoring.

For example in the Java world tools like Eclipse allow you to do extract method, push methods up/down the class hierarchy, add/remove attributes, etc. automatically. They become operations on the same level of granularity as "indent block", give you sensible error messages if the refactoring is impossible, and always work.

In Perl if I want to extract a method I have to select the code I want as a separate method. Wrap in in sub {}. Figure out what local vars it needs and pass them as arguments. Figure out what local vars it creates/changes and are used by the rest of the method and return them as results. Add the call to the new method into the old code. Spend a second or two looking at it to make sure I've not missed anything. Re-run the tests just to be sure.

If I'm writing Java in IntelliJ all I do is select the code I want as a separate method, hit Ctrl-Alt-M, type in the new method name and hit return.

It takes longer to describe that it does to do. The IDE does all the tedious make-work for me and it always works so I don't have to spend brain power catching my own typos or running tests to make sure that I didn't break anything.

This is just one example, but I hope it indicates how much developer time decent automated refactoring tools can save. Working without them is like working with an editor that forces me to indent blocks of text by moving the cursor to the start of each line and typing four spaces.

Fortunately Perl makes me more efficient in other ways, so it's still worth while. However I'd really like to be even more efficient - so good refactoring support is top of my list of wishes for my mythical ideal Perl development environment.

The problem is that doing decent refactoring support in Perl is non-trivial. Partly because of the only-perl-parsing-perl problem. Partly because of it's TMTOWTDI nature. Partly due to its flexible runtime nature.

The closest we have at the moment is EPIC/Devel::Refactor which only gives us a fair stab at method extraction. We do now have PPI which is an impressive piece of work and may make future development of Perl refactoring tools considerably easier.

I imagine that Perl 6's explicit grammar is going to make refactoring support considerably easier for that for Perl 5. Still tricky, just not completely insane :-)

[BUU]

Wow. An elightening explanation. One more question though. You say when you're extracting methods for the perl code, "Figure out what local vars it needs and pass them as arguments". Why don't you have to do this for the java code?

As I was writing this, it occurred to me that you don't have to do it because the java one scans your selection for variables and automatically determines which variables you need passed. In which case, I really think that's fairly doable in the perlworld, especially now that we have PPI.

I have to admit, the entire point of this thread was so I could think of something cool to do with PPI, as I think it's a really incredible module.. I just couldn't think of anything useful to do with it!

As an example, if you had this as your code selection:

my $x = frob( $bz );
print $x + $z;
foobar( $x );

Using the power of PPI it should be trivial to generate a new method:

sub methodname
{
  my ($bz, $z ) = @_;

  my $x = frob($bz;
  print $x + $z;
  foobar( $x );
}

Is that more or less what you had in mind?

[adrianh]

As I was writing this, it occurred to me that you don't have to do it because the java one scans your selection for variables and automatically determines which variables you need passed.

Yup.

Using the power of PPI it should be trivial to generate a new method ... Is that more or less what you had in mind?

Yup. With the addition of the original selection being replaced by a call to the new method. extract_subroutine() from Devel::Refactor does a fair job of this particular task already.