-=pod
+package Moose::Manual::Construction;
+
+# ABSTRACT: Object construction (and destruction) with Moose
-=head1 NAME
+__END__
-Moose::Manual::Construction - Object construction (and destruction) with Moose
+=pod
=head1 WHERE'S THE CONSTRUCTOR?
B<Do not define a C<new()> method for your classes!>
-When you C<use Moose> in your class, you will become a subclass of
-L<Moose::Object>, which provides a C<new> method for you. If you
-follow our recommendations in L<Moose::Manual::BestPractices> and make
-your class immutable, then you actually get a class-specific C<new>
+When you C<use Moose> in your class, your class becomes a subclass of
+L<Moose::Object>. The L<Moose::Object> provides a C<new()> method for your
+class. If you follow our recommendations in L<Moose::Manual::BestPractices>
+and make your class immutable, then you actually get a class-specific C<new()>
method "inlined" in your class.
=head1 OBJECT CONSTRUCTION AND ATTRIBUTES
=head1 OBJECT CONSTRUCTION HOOKS
Moose lets you hook into object construction. You can validate an
-object's state, do logging, or maybe allow non-hash(ref) constructor
+object's state, do logging, customize construction from parameters which
+do not match your attributes, or maybe allow non-hash(ref) constructor
arguments. You can do this by creating C<BUILD> and/or C<BUILDARGS>
methods.
The C<BUILDARGS> method is called as a class method I<before> an
object is created. It will receive all of the arguments that were
-passed to C<new> I<as-is>, and is expected to return a hash
+passed to C<new()> I<as-is>, and is expected to return a hash
reference. This hash reference will be used to construct the object,
so it should contain keys matching your attributes' names (well,
C<init_arg>s).
accommodate this calling style:
around BUILDARGS => sub {
- my $orig = shift;
+ my $orig = shift;
my $class = shift;
- if ( @_ == 1 && ! ref $_[0] ) {
- return $class->$orig(ssn => $_[0]);
+ if ( @_ == 1 && !ref $_[0] ) {
+ return $class->$orig( ssn => $_[0] );
}
else {
return $class->$orig(@_);
}
};
-Note the call to C<< $class->$orig >>. This will call the default
-C<BUILDARGS> in L<Moose::Object>. This method handles distinguishing
-between a hash reference and a plain hash for you.
+Note the call to C<< $class->$orig >>. This will call the default C<BUILDARGS>
+in L<Moose::Object>. This method takes care of distinguishing between a hash
+reference and a plain hash for you.
=head2 BUILD
The C<BUILD> method is called I<after> an object is created. There are
-several ways to use a C<BUILD> method. One of the most common is to
+several reasons to use a C<BUILD> method. One of the most common is to
check that the object state is valid. While we can validate individual
attributes through the use of types, we can't validate the state of a
whole object that way.
debug( 'Made a new person - SSN = ', $self->ssn, );
}
-Note that while it is not shown here, the C<BUILD> method receives
-not only the created object, but also a hashref of the original
-arguments passed to new (or the results of your C<BUILDARGS>,
-if you have overridden the default C<BUILDARGS>.) This can be
-useful if you need to venture beyond what the default
-initialization behavior and coercions can accomplish.
+
+The C<BUILD> method is called with the hash reference of the parameters passed
+to the constructor (after munging by C<BUILDARGS>). This gives you a chance to
+do something with parameters that do not represent object attributes.
+
+ sub BUILD {
+ my $self = shift;
+ my $args = shift;
+
+ $self->add_friend(
+ My::User->new(
+ user_id => $args->{user_id},
+ )
+ );
+ }
=head3 BUILD and parent classes
-The interaction between multiple C<BUILD> methods in an inheritance
-hierarchy is different from normal Perl methods. B<You should never
-call C<< $self->SUPER::BUILD >>.>
+The interaction between multiple C<BUILD> methods in an inheritance hierarchy
+is different from normal Perl methods. B<You should never call C<<
+$self->SUPER::BUILD >>>, nor should you ever apply a method modifier to
+C<BUILD>.
Moose arranges to have all of the C<BUILD> methods in a hierarchy
called when an object is constructed, I<from parents to
C<DEMOLISH> methods in your hierarchy to be called, from most to least
specific.
+Each C<DEMOLISH> method is called with a single argument.
+
In most cases, Perl's built-in garbage collection is sufficient, and
you won't need to provide a C<DEMOLISH> method.
-=head1 AUTHOR
-
-Dave Rolsky E<lt>autarch@urth.orgE<gt>
+=head2 Error Handling During Destruction
-=head1 COPYRIGHT AND LICENSE
+The interaction of object destruction and Perl's global C<$@> and C<$?>
+variables can be very confusing.
-Copyright 2009 by Infinity Interactive, Inc.
+Moose always localizes C<$?> when an object is being destroyed. This means
+that if you explicitly call C<exit>, that exit code will be preserved even if
+an object's destructor makes a system call.
-L<http://www.iinteractive.com>
+Moose also preserves C<$@> against any C<eval> calls that may happen during
+object destruction. However, if an object's C<DEMOLISH> method actually dies,
+Moose explicitly rethrows that error.
-This library is free software; you can redistribute it and/or modify
-it under the same terms as Perl itself.
+If you do not like this behavior, you will have to provide your own C<DESTROY>
+method and use that instead of the one provided by L<Moose::Object>. You can
+do this to preserve C<$@> I<and> capture any errors from object destruction by
+creating an error stack.
=cut
projects / gitmo/Moose.git / blobdiff