• Run PHP tests in your Perl test suite

    Sometimes you've got a big codebase that isn't just Perl. Maybe you've got PHP mixed in with it, and you want to test the PHP along with all the Perl code, too. Perl's *prove* program doesn't care if the testing results it parses are from Perl, PHP or even static files, so long as they're in the [TAP](http://testanything.org/) format. However, actually getting *prove* to run those PHP programs takes a little doing. Fortunately, Test::Harness 3.xx has hooks for source handlers.

    Read on →

  • Vim 7.3 supports Perl 6, adds Perl 5 improvements

    Vim 7.3 has just been released today. From the announcement:

    This is a minor release of Vim. It consists of Vim 7.2 plus all patches, updated runtime files and some more, see below. It has been two years since the 7.2 release, thus it's not that "minor". But not "major" either. Something in between, don't know how to call that.

    The most notable additions since 7.2:

    • Persistent undo and undo for reload
    • Blowfish encryption, encryption of the swap file
    • Conceal text
    • Lua interface
    • Python 3 interface

    However, to the Perl programmer, this is a significant upgrade from 7.2, because of updates of all the Perl-related support files. Vim has language specific plugins for syntax highlighting, indenting and other filetype-related behaviors. Every one of these Perl-related support files has been updated. For example, syntax/perl.vim has not been updated since 2006. Now, Perl 5.10 keywords like given, when and state are properly highlighted.

    For the Perl 6 hackers out there working with Rakudo Star, Vim now includes support for Perl 6. Until now, if Perl 6 programmers wanted Vim to support Perl 6, they had to use a perl6.vim file that got passed around from person to person. Now, it comes installed automatically as part of Vim 7.3.

    Perl 6 detection is primitive, so you may have to explicitly add it to your modeline in your file, such as

    # vi: filetype=perl6:

    All of these changes are from the vim-perl project hosted on Github. In that project, I've aggregated syntax, indent and filetype plugins for the Perl and Perl 6 support files that get fed back to the Vim project. It's also got support for other filetypes like Template Toolkit that are not part of the vim distribution. I'm not making many changes to the Vim code directly. Like many of my other contributions to open source, my role is one of wrangler and coordinator and less of programmer and technologist.

    If you're interested in Vim support for Perl 5 and Perl 6, I encourage you to check out the vim-perl project and join the vim-perl mailing list. Now that Vim 7.3 is out, we have some room to stretch out and make Vim do incredible things for Perl in the next release.

  • Perl is not an acronym

    A reminder to those out there, especially HR folks, that the language Perl is always spelled “Perl” and never “PERL.” From the Perl FAQ:

    Read on →

  • Why roles in Perl are awesome

    by Chris Prather

    A question came up recently on a mailing list. I was talking about how Roles are a awesome win for Perl5 considering how few languages implement the concept1. Someone asked what the win was with Roles. I happen to have been thinking about this recently and dashed off a reply.

    When you use Inheritance, especially multiple inheritance, for behavioral re-use you run into several problems quickly.

    First Inheritance is an explicit modeling of a relationship that carries semantic meaning. Let's say you're developing a game for Biology students to explain to them taxonomy. In this game a Dog class is a subclass of Animal. That is, the Dog class inherits specific behaviors and attributes from the Animal class. This probably isn't even a direct relationship your Dog class may inherit from a Mammal class which inherits from a Vertebrate class which inherits from Animalia which itself inherits from Life. These kinds of hierarchies are common in Taxonomy as well as in Object Oriented programming. However when you need to express something that may cross cut concerns in, you run into issues.

    Say for example your marketing department has had trouble selling this product to schools and is attempting to market to parents directly. They have done studies and kids really like Pets2. So your boss comes to you because the company wants you to add the concept of Pet to your Taxonomy model.

    Pets don't fit into a Taxonomy, it's obvious that not all Animalias are Pets3 and some Pets may not be animals at all4. In many languages can use Multiple Inheritance to describe this new "I'm an Animalia and a Pet" relationship but often you run into issues there as well. Is a Pet a Life? That would mean our object model would look like:

    Canine    Pet

    Pet stands out like a sore thumb. Obviously we've got issues with this new modeling. We talk to our boss and figure out that the rules for Pet are simple. Pet's are always domesticated versions of the Animalia, but not every class in Animalia is a pet. So for example Dogs are always Pets, Wolves are not. We can solve this with multiple inheritance now, but it's really not a clean way to express the relationship and it requires us to document the special relationship the Pet class would have with the rest off the Inheritance tree. Once you get beyond a few "special cases" like this it becomes hard to see the model for the exceptions.

    This is why some languages like to disallow multiple inheritance entirely. In Java for example, Pet could become an Interface.

    public interface Pet {
    Date getYearDomesticated;

    This however means that every class that we want to be a pet needs to have the exact same piece of boiler plate code added to it.

    class Dog implements Pet {
    private Date yearDomesticated;
    public Date getYearDomesticated () { this.yearDomesticated }

    If we instead have the concept of Roles then we can apply the concept of a Pet once at any level of the hierarchy we need. A example using a modern Perl5

    package Pet {
    use Moose::Role
    has year_domesticated => (
    is => 'ro',
    isa => 'DateTime',
    required => 1
    package Dog {
    use Moose;
    extends qw(Canine);
    with qw(Pet);

    The Pet Role here implements everything we need for a default implementation, and doesn't require more boiler plate to our Dog class, that the bare minimum needed. It also avoids the ugly inheritance issues we saw with multiple inheritance by moving the behavior composition onto different tool. In my opinion, Roles aren't a win for every use of inheritance, nor for every time you want to re-use behavior, but they are an excellent tool to have in the box and one that the Moose crowd knows to reach for quite often.

    1. Off the top of my head I only know about Perl5, Perl6, Scala, Javascript, and Smalltalk. There may be other implementations out there. ↩

    2. The Marketing guy's daughter plays on WebKinz nightly. ↩

    3. Pet Shark's would be dangerous to say the least, and where would you keep a pet Blue Whale? ↩

    4. Who doesn't love their Pet Rock? ↩

    5. We're using the the inline package syntax that will be released in 5.14 ↩

    Chris Prather is an Owner at Tamarou LLC, a member of the Moose cabal, and responsible for Task::Kensho.

  • Low-tech high-speed OS X program launching

    I work in my OS X Terminal window all day long. When I want to run iCal or Address Book, I don't want to be bothered with clicking around to find the app, even though they live in my Dock. I could also use a program launcher like [Alfred](http://alfredapp.com/), which I like, but want it even faster. For me, the fastest way to open iCal while I'm in the shell is to run "ical" from the prompt, which launches the app. My ~/bin/ical program is simply #!/bin/sh open /Applications/iCal.app/ and my ~/bin/addr is #!/bin/sh open "/Applications/Address Book.app/" You might think that it's overkill to write a shell program for such a silly task, but it's all about optimizing my time at the keyboard for my common cases. Someone will note that I could have used a shell alias, and that's true, too. Either way, I want a super simple way to get the apps I use most often.