NAME

Method::Signatures - method declarations with prototypes and no source filter

SYNOPSIS

package Foo;

use Method::Signatures;

method new (%args) {
    return bless {%args}, $self;
}

method get ($key) {
    return $self->{$key};
}

method set ($key, $val) {
    return $self->{$key} = $val;
}

DESCRIPTION

This is ALPHA SOFTWARE which relies on YET MORE ALPHA SOFTWARE. Use at your own risk. Features may change.

Provides a proper method keyword, like "sub" but specificly for making methods. Also a prototype declaration. Finally it will automatically provide the invocant as $self. No more my $self = shift.

And it does all this with no source filters.

Prototype syntax

At the moment the prototypes are very simple.

method foo($bar, $baz) {
    $self->wibble($bar, $baz);
}

is equivalent to:

sub foo {
    my $self = shift;
    my($bar, $baz) = @_;
    $self->wibble($bar, $baz);
}

except the original line numbering is preserved.

No checks are made that the arguments being passed in match the prototype.

Future releases will add extensively to the prototype syntax probably along the lines of Perl 6.

Aliased references

A prototype of \@foo will take an array reference but allow it to be used as @foo inside the method.

package Stuff;
method foo(\@foo, \@bar) {
    print "Foo:  @foo\n";
    print "Bar:  @bar\n";
}

Stuff->foo([1,2,3], [4,5,6]);

The @_ prototype

The @_ prototype is a special case which only shifts $self. It leaves the rest of @_ alone. This way you can get $self but do the rest of the argument handling manually.

PERFORMANCE

There is no performance penalty for using this module.

BUGS, CAVEATS and NOTES

Please report bugs and leave feedback at <bug-Method-Signatures> at <rt.cpan.org>. Or use the web interface at http://rt.cpan.org. Report early, report often.

Debugging

This totally breaks the debugger. Will have to wait on Devel::Declare fixes.

No source filter

While this module does rely on the hairy black magic of Devel::Declare and Data::Alias it does not depend on a source filter. As such, it doesn't try to parse and rewrite your source code and there should be no weird side effects.

Devel::Declare only effects compilation. After that, it's a normal subroutine. As such, for all that hairy magic, this module is surprisnigly stable.

What about regular subroutines?

Devel::Declare cannot yet change the way sub behaves. It's being worked on and when it works I'll release another module unifying method and sub.

What about class methods?

Right now there's no way to declare method as being a class method, or change the invocant, so the invocant is always $self. This is just a matter of coming up with the appropriate prototype syntax. I may simply use the Perl 6 ($invocant: $arg) syntax though this doesn't provde type safety.

What about types?

I would like to add some sort of types in the future or simply make the prototype handler pluggable.

What about the return value?

Currently there is no support for types or declaring the type of the return value.

What about anonymous methods?

...what would an anonymous method do?

THANKS

This is really just sugar on top of Matt Trout's Devel::Declare work.

Also thanks to Matthijs van Duin for his awesome Data::Alias which makes the \@foo prototype work perfectly and Sub::Name which makes the subroutine names come out right in caller().

LICENSE

The original code was taken from Matt S. Trout's tests for Devel::Declare.

Copyright 2007-2008 by Michael G Schwern <schwern@pobox.com>.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

See http://www.perl.com/perl/misc/Artistic.html

SEE ALSO

Sub::Signatures, Perl6::Subs

Perl 6 subroutine parameters and arguments - http://perlcabal.org/syn/S06.html#Parameters_and_arguments