Still having posted my last little ditty on having role attached to Moose I thought I make some slight amendments to MooseX::SingletonMethod module to pull this slightly annoying thorn from my paw.

Version 0.02 will soon be on CPAN and now works either of these ways:

package Baz;
use MooseX::SingletonMethod;
...
no MooseX::SingletonMethod;
1;

or as a role:

package Baz;
use Moose;
with 'MooseX::SingletonMethod::Role';
...
no Moose;
1;

Hate to change API but MX::SM is only a a few weeks old so I’m hopeful that the hordes of users that use this module will understand

/I3az/

Moritz is absolutely correct so I’ll make immediate amends by reproducing the core of my last post about how Moose Roles implemented singleton methods with some helpful diagrams.

So first here is the initial Animal class code again:

use MooseX::Declare;

class Animal {
    method walk { "unknown" }
    method wild { "wild?... I'm bliming livid!" }
}

my $baz = Animal->new;

Here is a diagram which shows the object ($baz) & each class with its methods:

From this we can see that:

• $baz is the instantiated object of the Animal class.
• The Animal class contains all the methods we defined (along with “new” & “meta”) and its superclass is Moose::Object.

NB. Moose::Object is the ultimate superclass which all Moose classes relate back to. In Moose::Object we can see all the base methods.

Next is the DoesHuman role and it being applied to the $baz object:

role DoesHuman {
    method walk { "when not drunk!" }
    method legs { 2 }
}

DoesHuman->meta->apply( $baz );

And finally this is how the class relationship now looks for $baz object after the above role was applied:

The anonymous class was created when the DoesHuman role was applied to $baz object and it now stands proudly at the front of the inheritance chain for $baz object.

Thus we have added singleton method(s) to an object by using Moose roles.

This is a clear example of a picture being definitely worth a thousand words

So to help explain all this I’ll create a simple (contrived!) example:

use MooseX::Declare;

class Animal {
    method walk { "unknown" }
    method wild { "wild?... I'm bliming livid!" }
}

Now if we introspect this:

my $baz = Animal->new;
say "baz is an Animal and its " . $baz->walk . " if he can walk or not?";
say "baz methods are: ", join " | ", $baz->meta->get_method_list;
say "baz ISA: ", join " | ", $baz->meta->class_precedence_list;

We will see this:

baz is an Animal and its unknown if he can walk or not?
baz methods are: walk | new | wild | meta
baz ISA: Animal | Moose::Object

Using get_method_list returns methods just in this class (running get_all_method_names would return all resolvable methods via inheritance).

And using class_precedence_list returns the class interitance chain starting with its own class Animal. NB. Moose::Object is the base class for all Moose objects.

So no surprises here. So what happens when I sprinkle some fairy dust on $baz by applying a role to this object (and creating a Singleton Method):

role DoesHuman {
    method walk { "when not drunk!" }
    method legs { 2 }
}

DoesHuman->meta->apply( $baz );

say "baz is now Human with " . $baz->legs . " legs and walks " . $baz->walk;
say "baz methods are: ", join " | ", $baz->meta->get_method_list;
say "baz ISA: ", join " | ", $baz->meta->class_precedence_list
say "baz says: ", $baz->wild;

This produces:

baz is now Human with 2 legs and walks when not drunk!
baz methods are: legs | walk | meta
baz ISA: Class::MOP::Class::__ANON__::SERIAL::2 | Animal | Moose::Object
baz says: wild?… I’m bliming livid!

First lets look at the object methods. legs has been added and walk has also nicely been replaced. So this does exactly what I asked it to do.

But hold on… where has wild gone from the method list? And yet when I do $self->wild it works fine??

Well if you followed Dave Thomas video link I gave in first post then this is easily explained (even though he’s talking about Ruby!).

If you look at the class inheritance you can see what happened. Here is my attempt to explain whats going on:

Applying DoesHuman role to $baz object has created new anonymous class called (in this instance) “Class::MOP::Class::__ANON__::SERIAL::2″ and puts the DoesHuman role methods legs and walk into there and then makes this class a child of Animal. $baz is then assigned (blessed) to this new anon class.

Or has Dave Thomas says:

move one to the right and then up one

But that only makes sense if you use same diagrams he had!

All very neat! In a nutshell its created a unique anonymous class with the role methods which $baz uses instead of the Animal class.

And you can keep adding to this anon class chaining:

role DoesMale {
    method sex  { "male" }
    method wild { "nice to meet u!" }
}

DoesMale->meta->apply( $baz );

say "baz is now a " . $baz->sex;
say "baz methods are: ", join " | ", $baz->meta->get_method_list;
say "baz ISA: ", join " | ", $baz->meta->class_precedence_list;
say "baz says: ", $baz->wild;

baz is now a male
baz methods are: sex | wild | meta
baz ISA: Class::MOP::Class::__ANON__::SERIAL::3 | Class::MOP::Class::__ANON__::SERIAL::2 | Animal | Moose::Object
baz says: nice to meet u!

/I3az/

Some references:

1. Roles, Singleton Methods & MooseX::Declare
2. Using Moose Roles to create Singleton Methods
3. Moose::Manual::MOP
4. CLass::MOP::Class or (kobesearch)

p := 4 @ 3.
p changeClassTo: (p class copy superclass: p class).
p class methodDictionary at: #negated put: (p class methodDictionary at: #transpose).
p negated


My exposure to Smalltalk is limited to a quick look at Seaside web framework which is a bit like learning Rails instead of starting with Ruby

I can just about grok what this code does. Thankfully Rick DeNatale provided a nice Ruby conversion

Here is Rick’s subset of Smalltalk’s Point which replicates what the first Smalltalk line “p := 4 @ 3.” does:

class Point
  attr_accessor :X, :y    # :X should be lowercase but Wordpress keeps converting it to a smiley!

  def initialize(x, y)
    @x, @y = x, y
  end

  def negated
    self.class.new(-x, -y)
  end

  def transpose
    self.class.new(y, x)
  end

  def inspect
    "#{@x} @ #{@y}"
  end
end


p = Point.new(4,3)

p.negated          # => -4 @ -3
p.transpose        # => 3 @ 4

So negated & transpose methods return new Point objects so all very straightforward so far.

In the Smalltalk code the object negated method gets amended to use the transpose method instead.
You can do this in Ruby by opening up the objects method like so:

def p.negated
  transpose
end

p.negated          # => 3 @ 4
p.transpose        # => 3 @ 4

Nice eh! The Ruby world refer to this has a Singleton Method. These are methods which are defined in the object and not the class.

I highly recommend watching this excellent video talk by Dave Thomas which provides excellent lucidity to how Ruby objects work.

Now how about Perl? I suspect you can use some MOP meta magic to do same but did you know that Moose Roles can be applied directly to objects?

Here’s is the Ruby Point code in Perl using classic Moose.

{
    package Point;
    use Moose;

    has x => ( isa => 'Int', is => 'rw' );
    has y => ( isa => 'Int', is => 'rw' );

    sub negated {
        my $self = shift;
        $self->new( x => -$self->x, y => -$self->y );
    }

    sub transpose {
        my $self = shift;
        $self->new( x => $self->y, y => $self->x );
    }

    sub inspect { say "$_[0]->{x} \@ $_[0]->{y}" }
    
    no Moose;
}


my $p = Point->new( x => 4, y => 3 );

$p->negated->inspect;     # => -4 @ -3
$p->transpose->inspect;   # => 3 @ 4

So all works same as the Ruby example. Now if we create a role like so:

{
    package Negated;
    use Moose::Role;
    
    requires 'transpose';
    
    sub negated { 
        my $self = shift;
        $self->transpose;
    }
    
    no Moose::Role;
}

You can then “apply” it to any object like so:

Negated->meta->apply( $p );
$p->negated->inspect;     # => 3 @ 4
$p->transpose->inspect;   # => 3 @ 4

Lovely jubbly!

And as we’ve gone down this Moose Role route we might as well wrap it all up like this:

{
    package Point;
    use Moose;

    with qw/DoesNegated DoesTranspose/;
    
    has x => ( isa => 'Int', is => 'rw' );
    has y => ( isa => 'Int', is => 'rw' );

    sub inspect { say "$_[0]->{x} \@ $_[0]->{y}" }
    
    no Moose;
}

{
    package DoesNegated;
    use Moose::Role;
        
    sub negated {
        my $self = shift;
        $self->new( x => -$self->x, y => -$self->y );
    }
    
    no Moose::Role;
}

{
    package DoesTranspose;
    use Moose::Role;
        
    sub transpose {
        my $self = shift;
        $self->new( x => $self->y, y => $self->x );
    }
    
    no Moose::Role;
}

my $p = Point->new( x => 4, y => 3 );

DoesTranspose->meta->apply( $p, alias => { transpose => 'negated' } );

$p->negated->inspect;     # => 3 @ 4
$p->transpose->inspect;   # => 3 @ 4

This time I used the “alias” option to rename the applied method on the Moose hoof

And u can keep applying roles to objects at your hearts content adding or replacing methods
as many times as u like.

/I3az/

Some references:

• Moose Cookbook Roles Recipe 3
• my Stackoverflow answer about applying roles on objects