Nov 26

I’ve been meaning to try Method::Signatures::Simple ever since the last YAPC and just finally found the time. Something about typing “my ($self) = @_” for the millionth time pushing me over the edge.

Converted a random module in Mason 2. Reduced the number of lines by 65 (10%) and I feel like I’m developing in a modern language again. I’m hooked! Hats off to Rhesa Rozendaal and those responsible for the underlying Devel::Declare.

Now I’m eager to convert Mason 2 and possibly CHI to this across the board. The question is, is it reasonable for me to use this in published CPAN modules? It seems like very few CPAN modules do, and given how clearly awesome it is :) , I’m wondering if there is a reason, other than not wanting the extra dependency or not wanting to depend on “black magic”.

One snag is that perltidy (which I use rigorously on commit) doesn’t yet recognize the ‘method’ keyword. I managed to fix by patching Perl::Tidy to allow arbitrary transformations before and after tidying – so I can replace ‘method’ with ‘sub’ beforehand and convert back afterwards. Will attempt to contribute this back.

10 Responses to “Another Method::Signatures::Simple convert”

  1. john napiorkowski Says:

    I think this module was sort of intended for the use where MooseX::Declare is either overkill or where it’s memory and performance is too much an issue but where as you say, you want to feel like you are writing Modern Perl. Its got a very good install rate on CPAN so as a Mason 1.x user I have no problem seeing it in the source.

  2. Jonathan Swartz Says:

    john n: Thanks. Just curious, when you say “very good install rate on CPAN”, what exactly are you referring to?

  3. john napiorkowski Says:

    I guess I should have said, “Passes tests a lot!”, http://www.cpantesters.org/distro/M/Method-Signatures-Simple.html#Method-Signatures-Simple-0.06

    In retrospect, “installability” probably wasn’t the best way to express that.

  4. fREW Schmidt Says:

    I think part of the issue is that Devel::Declare requires a compiler, which may make life hard for some deployments.

  5. Jonathan Swartz Says:

    fREW: Good point. IIRC, Moose and/or Class::MOP also require a compiler. So perhaps it is safe to say that if a module already depends on Moose (as CHI does and Mason 2 will), then additionally depending on Devel::Declare will not significantly increase the difficulty of installation?

  6. Peter Rabbitson Says:

    The convenience also comes at an (arguably minimal) price. While a 10% invocation slowdown is not that big of a deal, it might very well show up in something as latency sensitive as CHI.

    use strictures 1;
    use Method::Signatures::Simple;
    use Benchmark qw/cmpthese/;

    sub classic {
    my ($self, $f, $s) = @_;
    $f + $s;
    }

    sub optimized { $_[1] + $_[2] }

    method mss($f, $s) {
    $f + $s;
    }

    cmpthese (-1 => {
    classic => sub {
    for (1..1000) {
    my $foo = __PACKAGE__->classic (2, 3);
    }
    },
    optimized => sub {
    for (1..1000) {
    my $foo = __PACKAGE__->optimized (2, 3);
    }
    },
    mss => sub {
    for (1..1000) {
    my $foo = __PACKAGE__->mss (2, 3);
    }
    },
    });

    __END__

    ### Results

    Rate mss classic optimized
    mss 593/s — -8% -45%
    classic 646/s 9% — -40%
    optimized 1071/s 81% 66% –

  7. Douglas Wilson Says:

    Peter: I’m not sure where MMS is getting the run-time overhead from, though your test script it’s a *true* comparison between classic and MMS, as mms uses shift for the self. I added a sub that does the shift to @_ for self and unpack for the others (I call this “classic_mms”) and there is even less of a difference.

    Rate classic_mss mss classic optimized
    classic_mss 298/s — -2% -6% -69%
    mss 303/s 2% — -4% -69%
    classic 317/s 6% 5% — -67%
    optimized 969/s 225% 219% 205% –

    The rest of the run-time hit is the magic Devel::Declare leaves us with to name the subroutines in the tree.

  8. Perrin Harkins Says:

    “Breaks perltidy” is pretty much the definition of something I wouldn’t use.

  9. perltidy and ‘method’: happy together Says:

    [...] wrote previously about the inability of perltidy to handle the method keyword of Method::Signatures::Simple. Now, [...]

  10. Jonathan Swartz Says:

    Perrin: It’s pretty simple now to get perltidy to work with ‘method’:

    http://www.openswartz.com/2010/12/19/perltidy-and-method-happy-together/

    But I understand the sentiment – there’s a whole bunch of perl processing tools out there (perltidy, perlcritic, editor modes, etc.) and I tread very carefully before using tweaks like this. For me, ‘method’ is just too good not to use.

Leave a Reply

preload preload preload