waste resources (CPU, memory) on objects that won't work because of missing
resources?
+=head2 When would you use an Moose type constraint instead of a custom constructor?
+
+Using type constraints via L<Moose::Util::TypeConstraints>, you can verify
+simple relationships when an object is created:
+
+ package Triangle;
+ use Moose;
+
+ has
+
+You would want to use the C<BUILD()> method in order to verify more complex
+relationships:
+
+ package IsoscelesTriangle;
+ use Moose;
+
=head2 BUILD method is run only if it is defined in the object
If your object does not have a C<BUILD> method, then Moose will skip trying to
The code in this document will work on Moose as advertised, but the developers
strongly recommend using something like L<Moose::Autobox> or
L<MooseX::AttributeHelpers> when working with hash references in order to
-help keep your Moose objects nice and encapsulated.
+help keep your Moose objects nice and encapsulated. The reason why this POD
+exists is to show potential users of L<Moose> that Moose objects are just like
+Plain Ol' Perl Objects (POPO), albeit with some extra metadata syntatic sugar.
=head2 Assigning hashes to a HashRef attribute
my $avocado = Fruit->new( species => 'P. americana' );
$fruit_aisle_copy{avocado} = $avocado;
$store->fruit_aisle( \%fruit_aisle_copy );
+ $store->fruit_aisle->{avocado};
And here's an example of deleting existing key/value pairs:
%fruit_aisle_copy = %{$store->fruit_aisle};
delete($fruit_aisle_copy{tomato});
$store->fruit_aisle( \%fruit_aisle_copy );
+ delete $mooseObj->hashref->{foo};
Putting the above code into their own object methods would make appending to
and deleting from a C<HashRef> a trivial operation.