Type Constraints

    method foo (             $affe) # no type checking
    method bar (Animal       $affe) # $affe->isa('Animal')
    method baz (Animal|Human $affe) # $affe->isa('Animal') || $affe->isa('Human')

Positional vs. Named

    method foo ( $a,  $b,  $c) # positional
    method bar (:$a, :$b, :$c) # named
    method baz ( $a,  $b, :$c) # combined

Required vs. Optional

    method foo ($a , $b!, :$c!, :$d!) # required
    method bar ($a?, $b?, :$c , :$d?) # optional

Defaults

    method foo ($a = 42) # defaults to 42

Constraints

    method foo ($foo where { $_ % 2 == 0 }) # only even

Invocant

    method foo (        $moo) # invocant is called $self and is required
    method bar ($self:  $moo) # same, but explicit
    method baz ($class: $moo) # invocant is called $class

Labels

    method foo (:     $affe ) # called as $obj->foo(affe => $value)
    method bar (:apan($affe)) # called as $obj->foo(apan => $value)

Traits

    method foo (Affe $bar does trait)
    method foo (Affe $bar is trait)

The only currently supported trait is "coerce", which will attempt to coerce the value provided if it doesn't satisfy the requirements of the type constraint.

Placeholders

    method foo ($bar, $, $baz)

Sometimes you don't care about some parameters you're being called with. Just put the bare sigil instead of a full variable name into the signature to avoid an extra lexical variable to be created.

Complex Example

    method foo ( SomeClass $thing where { $_->can('stuff') }:
                 Str  $bar  = "apan",
                 Int :$baz! = 42 where { $_ % 2 == 0 } where { $_ > 10 } )

    # the invocant is called $thing, must be an instance of SomeClass and
           has to implement a 'stuff' method
    # $bar is positional, required, must be a string and defaults to "apan"
    # $baz is named, required, must be an integer, defaults to 42 and needs
    #      to be even and greater than 10

Fancy signatures

No source filter

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

What about regular subroutines?

What about the return value?

  method foo (Int $x, Str $y) returns (Bool) { ... }

however, this feature only works with scalar return values and is still considered to be experimental.

Interaction with Moose::Role

Because the processing of the MooseX::Method::Signatures "method" and the Moose "with" keywords are both done at runtime, it can happen that a role will require a method before it is declared (which will cause Moose to complain very loudly and abort the program).

For example, the following will not work:

    # in file Canine.pm

    package Canine;

    use Moose;
    use MooseX::Method::Signatures;

    with 'Watchdog';

    method bark { print "Woof!\n"; }

    1;


    # in file Watchdog.pm

    package Watchdog;

    use Moose::Role;

    requires 'bark';  # will assert! evaluated before 'method' is processed

    sub warn_intruder {
        my $self = shift;
        my $intruder = shift;

        $self->bark until $intruder->gone;
    }

    1;

A workaround for this problem is to use "with" only after the methods have been defined. To take our previous example, Canine could be reworked thus:

    package Canine;

    use Moose;
    use MooseX::Method::Signatures;

    method bark { print "Woof!\n"; }

    with 'Watchdog';

    1;

A better solution is to use MooseX::Declare instead of plain MooseX::Method::Signatures. It defers application of roles until the end of the class definition. With it, our example would becomes:

    # in file Canine.pm

    use MooseX::Declare;

    class Canine with Watchdog {
        method bark { print "Woof!\n"; }
    }

    1;

    # in file Watchdog.pm

    use MooseX::Declare;

    role Watchdog {
        requires 'bark';

        method warn_intruder ( $intruder ) {
            $self->bark until $intruder->gone;
        }
    }

    1;

Subroutine redefined warnings

When composing a Moose::Role into a class that uses MooseX::Method::Signatures, you may get a "Subroutine redefined" warning. This happens when both the role and the class define a method/subroutine of the same name. (The way roles work, the one defined in the class takes precedence.) To eliminate this warning, make sure that your "with" declaration happens after any method/subroutine declarations that may have the same name as a method/subroutine within a role.