Code Reuse with Moose

Hans Dieter Pearcey (hdp@cpan.org)

design patterns

invisible
formal
informal

Moose's role

enables a shift from informal to formal
Roles
- sharing code without requiring inheritance
Type Constraints / Coercions
- parameter validation / transformation
directions vs. intentions

Type Constraints

generic validation system
built-in types: Int, Str, HashRef, etc.

use MooseX::Types::Moose -all;
use MooseX::Types;

types can be parameterizable

ArrayRef[Int]

HashRef[Object]

Subtyping

declare your own types

use MooseX::Types -declare => [
  qw(PosInt PosEvenInt PosIntTriplet)
];

subtype PosInt,
  as Int, where { $_ > 0 },
  message { "Int is not greater than 0" };

subtype PosEvenInt,
  as PosInt, where { $_ % 2 == 0 },
  message { "Int is not even" };

subtype PosIntTriplet,
  as ArrayRef[PosInt], where { @$_ == 3 },
  message { "Must have exactly 3 PosInts" };

Type Constraint Use

use by hand

my $tc = find_type_constraint(HashRef);
if ($tc->check($input)) { ... }

use in attributes

has foo => (is => 'rw', isa => HashRef);

use in methods

use MooseX::Params::Validate;
sub foo {
  my ($self, %arg) = validated_hash(
    \@_,
    bar => { isa => Int },
  )
}

Libraries

export type definitions

package MyApp::Types;
use MooseX::Types -declare => [ qw(PosInt ...) ];
subtype PosInt, ...;

package MyApp;
use MyApp::Types qw(PosInt);

# don't let awesomeness drop to 0
has awesome => (isa => PosInt);

Type Constraints

Phase 1: validate
Phase 2: ???
Phase 3: profit!

Type Constraints

Phase 1: validate
Phase 2: coerce
Phase 3: profit!

Type Coercions

never write this again

sub read_data {
  my ($self, $from) = @_;
  open my $handle, '<', $from
    or die "Can't open file $from: $!";
  # ... do something with $handle
}

Type Coercions

never write this again

sub read_data {
  my ($self, $from) = @_;
  my $handle;
  if (! ref $from) {
    open $handle, '<', $from
      or die "Can't open file $from: $!";
  } else {
    die "Unhandled data source: $from"
  }
  # ... do something with $handle
}

Type Coercions

never write this again

sub read_data {
  my ($self, $from) = @_;
  my $handle;
  if (! ref $from) {
    open $handle, '<', $from
      or die "Can't open file $from: $!";
  } elsif (ref $from and ref $from eq 'GLOB') {
    $handle = $from;
  } else {
    die "Unhandled data source: $from"
  }
  # ... do something with $handle
}

Type Coercions

never write this again

sub read_data {
  my ($self, $from) = @_;
  my $handle;
  if (! ref $from) {
    open $handle, '<', $from
      or die "Can't open file $from: $!";
  } elsif (ref $from and ref $from eq 'GLOB') {
    $handle = $from;
  } elsif (ref $from and ref $from eq 'SCALAR') {
    open $handle, '<', $from
      or die "Can't open scalar ref: $!";
  } else {
    die "Unhandled data source: $from"
  }
  # ... do something with $handle
}

Type Coercions

instead, declare your own FileHandle type

use MooseX::Types::Moose
  FileHandle => { -as => 'MooseFileHandle' };
use MooseX::Types -declare => ['FileHandle'];

subtype FileHandle, as MooseFileHandle;

and coerce it from a string (Str)

coerce FileHandle,
  from Str,
  via {
    IO::File->new($_, 'r')
    or die "Can't open $_: $!"
  };

Put into place

package MyApp::Reader;
use Moose; 
use MyApp::Types qw(FileHandle);
has from => (
  is     => 'ro',
  isa    => FileHandle, 
  coerce => 1,
);

# elsewhere
$f = MyApp::Reader->new(from => $fh);
$f = MyApp::Reader->new(from => '/some/file');

Adding a coercion

back in MyApp::Types:

coerce FileHandle,
  from ScalarRef, 
  via { IO::File->new($_, 'r') };

then, use it:

$f = MyApp::Reader->new(from => \'a string');

Complete definition

use MooseX::Types::Moose
  FileHandle => { -as => 'MooseFileHandle' },
  qw(Str ScalarRef);
use MooseX::Types -declare => ['FileHandle'];

subtype FileHandle, as MooseFileHandle;

coerce FileHandle,
  from Str,
  via {
    IO::File->new($_, 'r')
    or die "Can't open $_: $!"
  };

coerce FileHandle,
  from ScalarRef, 
  via { IO::File->new($_, 'r') };

Conclusion

less code
more modular
refactor TCs like other code

Roles

describe behavior, not nature
- HasWhereClause
- MakesAliasObjects
'interfaces' 'mixins' 'traits'
named sets of exported methods, modifiers, and attributes
reusable pieces of class-related functionality
like duck typing, but explicitly named
- solves Dog vs. Tree

roles vs. inheritance

immediate composition, method resolution, conflict reporting
no lost/hidden methods, unlike multiple inheritance
stop writing this:

sub driver_name {
  croak "A subclass should override this!"
}

package MyApp::Driver;
requires 'driver_name';

examples

from Fey
SQL is complicated
lots of people need to deal with it
string concat and sprintf are insufficient

as interface

package Fey::Role::Named;
use Moose::Role;
requires 'name';

consumed by tables and columns

as label

package Fey::Role::Joinable;
use Moose::Role;
sub is_joinable { 1 }

consumed by tables and selects

as composed definition

Fey::Role::ColumnLike

combine smaller roles

as complex, standalone behavior

Fey::Role::SQL::HasWhereClause

attributes and accompanying methods

parameterized roles

Fey::Role::HasAliasName

parameter() -- has() for role construction
allows configuration of generated attributes / methods

SELECT
  (SELECT ...) AS SELECT0,
  SUBSTR(...)  AS FUNCTION0,
  ...

parameterized roles

sub driver_name {
  croak "A subclass should override this!"
}

package MyApp::Driver;
parameter driver_name => (isa => Str, required => 1);
role {
  my $p = shift;
  method driver_name => sub { $p->driver_name };
};

package MyApp::Driver::Wagon;
with 'MyApp::Driver' => { driver_name => 'wagon' };

applied to individual instances

WWW::Mechanize::TreeBuilder

my $mech = WWW::Mechanize->new;
WWW::Mechanize::TreeBuilder->meta->apply($mech);

$mech->look_down
doesn't change WWW::Mechanize

Role caveats

not for absolutely every situation
- use the rest of the MOP
cannot instantiate roles, only classes

the end

thank you!