You may have seen or played with the Smalltalk browser before:

GNU Smalltalk Gtk Browser

If you have, you'd love it. It makes it trivial to browse through, visualize and manage a project. However, we don't have anything like this for Perl. brian d foy has tried to create a Perl browser (with code on github), but that's the only significant effort in this direction I've seen. Padre has a ticket for a subset of this functionality, but as far as I can tell, it has the same limitation as brian's approach (please correct me if I'm wrong): it's file-based.

Given Perl's dynamic nature, what if we ditched the file-based heuristics and actually examine running code? I've been thinking about this.

My idea is as follows (pseudo-code):

package My::Project::Image;
use Moose;
with qw(Does::Perl::Image);

# any extra code, if needed, but the above should be enough
has dependencies => ( is => 'ro', isa => 'Str', required => 1 );

sub stop {
    # any needed cleanup to stop an image

And then to use the image, it would be something like this:

#!/usr/bin/env perl
use Modern::Perl
use My::Project::Image;
use My::Project;

my $image = My::Project::Image->new({
    lib   => 'lib/',
    tests => 't/',
    deps  => 'deps/lib',
    start => sub { My::Project->new },
    stop  => sub { shift->image->stop },

The idea is that you tell the image where to find the lib directory, the tests, and any extra information relevant to your image and then you pass it an init subref which runs some code to load the image in memory. In other words, you run code and we inspect what's actually in memory rather than use heuristics to analyse files.

There are several obstacles to this approach.

  • You can't disambiguate between methods and subroutines.
  • You can't disambiguate between classes and instances (heck, classes and module distinctions would get tossed).
  • The develop should be aware of side-effects from BEGIN blocks or similar issues.
  • Altering @ISA, diddling with namespaces and similar trickery could lead to an out-of-date image.

I think, perhaps, that this should spawn a separate thread and keep reloading an image whenever a given event occurs (you change a file, perhaps) and maybe have a SQLite backend to store image data. If the entire project was based on Moose, much of the utility of this would go away, but Moose doesn't help you when you're working with procedural code.

Also, integration with Devel::CoverX::Covered and similar tools would be useful.

Would something like this be feasible? Would it be worthwhile? I fear that Perl's ad-hoc OO system would limit much of the utility outside of Moose.


Class::MOP has a class browser somewhere that is a very very rudimentary version of what you're talking about I think.

The problems really boiled down to, Smalltalk and Perl are very different languages when it comes to their concept of what "code" is. I personally for example, am not sold on the Smalltalk idea of images as the "frozen" form of the application yet. It adds a lot of flexibility to the running program, but ties you very tightly to the specific set of tools that that can manipulate the image (since the image is no longer simply text files). If you think the vi vs emacs debates get silly, just wait till you start trying to argue that your application should be partially non-textual.

Context context context.

In some contexts image based programming in Perl could be really useful. While not useful in others.

Having the option is what makes Perl valuable.

Please don't misunderstand me (or god-forbid, take offense where none is intended). I'm not sure where I fall on this debate.

For example, I think thinks like Devel::Declare and the ability to extend the syntax of the language in extensions is important. It means that we can test new ideas about where we want the language to move to (eg. a class keyword, method signatures, and dynamic types all require various levels of new syntax). However I also understand how new syntax will make the implementation of tools like PPI and a Perl::Image more difficult. Especially if they use any kind of textual analysis to get their jobs done.

There is gonna be a long, interesting, and hopefully fruitful discussion over the next few years about the kinds and quality of tooling we want in our development process. I look forward to seeing what comes out of it.

Having the option is what makes Perl valuable.

As long as one of the options is to change one’s mind about the use of an image. I don’t care for images (for a variety of reasons, some of which purely personal idiosyncrasies), but as long as I can opt out at any point (ie. other people using them wouldn’t end up forcing me to follow suit), I would agree with you and would argue in favour of images, for those who want them. (I get the attraction, even if it doesn’t work on me.)

Leave a comment

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book!