merge trunk to pluggable errors

[gitmo/Moose.git] / lib / Moose / Cookbook / Basics / Recipe9.pod

=pod

=head1 NAME

Moose::Cookbook::Basics::Recipe9 - Builder methods and lazy_build

=head1 SYNOPSIS

  package BinaryTree;
  use Moose;

  has 'node' => (is => 'rw', isa => 'Any');

  has 'parent' => (
      is        => 'rw',
      isa       => 'BinaryTree',
      predicate => 'has_parent',
      weak_ref  => 1,
  );

  has 'left' => (
      is        => 'rw',
      isa       => 'BinaryTree',
      predicate => 'has_left',
      lazy      => 1,
      builder   => '_build_child_tree',
  );

  has 'right' => (
      is        => 'rw',
      isa       => 'BinaryTree',
      predicate => 'has_right',
      lazy      => 1,
      builder   => '_build_child_tree',
  );

  before 'right', 'left' => sub {
      my ($self, $tree) = @_;
      $tree->parent($self) if defined $tree;
  };

  sub _build_child_tree {
      my $self = shift;

      return BinaryTree->new( parent => $self );
  }

=head1 DESCRIPTION

If you've already read L<Moose::Cookbook::Basics::Recipe3>, then this example
should look awfully familiar. In fact, all we've done here is replace
the attribute C<default> with a C<builder> method.

In this particular case, the C<default> and C<builder> options act in
exactly the same way. When the C<left> or C<right> attribute get
method is called, Moose will call the builder method to initialize the
attribute.

Note that Moose calls the builder method I<on the object which has the
attribute>. Here's an example in code:

  my $tree = BinaryTree->new();

  my $left = $tree->left();

At this point, Moose will call C<< $tree->_build_child_tree() >> in
order to populate the C<left> attribute. If we had passed C<left> to
the original constructor, the builer would not be called.

=head2 Subclassable

There are some differences between C<default> and C<builder>. Because
C<builder> is called I<by name>, it goes through Perl's normal
inheritance system. This means that builder methods are both
inheritable and overrideable.

For example, we might make a C<BinaryTree> subclass:

  package TrinaryTree;
  use Moose;

  extends 'BinaryTree';

  has 'middle' => (
      is        => 'rw',
      isa       => 'BinaryTree',
      predicate => 'has_middle',
      lazy      => 1,
      builder   => '_build_child_tree',
  );

This doesn't quite work though. If you look closely at the
C<_build_child_tree> method defined in C<BinaryTree>, you'll notice
that it hard-codes a class name. Naughty us!

Also, as a bonus, we'll pass C<@_> through, so subclasses can override
the method to pass additional options to the constructor.

Good object-oriented code should allow itself to be subclassed
gracefully. Let's tweak C<_build_child_tree>:

  sub _build_child_tree {
      my $self = shift;

      return (ref $self)->new( parent => $self, @_ );
  }

Now C<_build_child_tree> can be gracefully inherited and overridden.

=head2 Composable

There's more to builders than just subclassing, though. The fact that
builders are called by name also makes them suitable for use in a
role.

  package HasAnimal;
  use Moose::Role;

  requires '_build_animal';

  has 'animal' => (
      is      => 'ro',
      isa     => 'Animal',
      lazy    => 1,
      builder => '_build_animal',
  );

This role provides an animal attribute, but requires that the consumer
of the role provide a builder method it.

  package CatLover;
  use Moose;

  with 'HasAnimal';

  sub _build_animal {
      return Cat->new();
  }

=head2 The lazy_build shortcut

The C<lazy_build> attribute parameter can be used as sugar to specify
a whole bunch of options at once.

  has 'animal' => (
      is         => 'ro',
      isa        => 'Animal',
      lazy_build => 1,
  );

This is a shorthand for this:

  has 'animal' => (
      is        => 'ro',
      isa       => 'Animal',
      required  => 1,
      lazy      => 1,
      builder   => '_build_animal',
      predicate => 'has_animal',
      clearer   => 'clear_animal',
  );

If your attribute starts with an underscore, Moose is smart and will
do the right thing with the C<predicate> and C<clearer>, making them
both start with an underscore. The C<builder> method I<always> starts
with an underscore, since you will want this to be private the vast
majority of the time.

Note that the C<builder> method name is created by simply taking
"_build_" and appending the attribute name. This means that attributes
with a leading underscore like C<_animal> end up with a builder named
C<_build__animal>.

=head1 CONCLUSION

The C<builder> option is a more OO-friendly version of the C<default>
functionality. It also has the property of separating out the code
into a separate well-defined method. This alone makes it valuable. It
is quite ugly to jam a long default code reference into your attribute
definition.

Here are some good rules for determining when to use C<builder> vs
C<default>.

If the default value is a simple scalar that only needs to be
calculated once (or a constant), use C<default>.

If the default value is an empty reference that needs to be wrapped in
a coderef like C<sub { [] }>, use C<default>.

Otherwise, use C<builder>.

This ensures that your classes are easily subclassable, and also helps
keep crufty code out of your attribute definition blocks.

=head1 AUTHOR

Dave Rolsky E<lt>autarch@urth.orgE<gt>

=head1 COPYRIGHT AND LICENSE

Copyright 2006-2008 by Infinity Interactive, Inc.

L<http://www.iinteractive.com>

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

=cut