Revision history for Perl extension Moose
0.52
+ * Moose::Cookbook::Snacks::*
+ - removed some of the unfinished snacks that should
+ not have been released yet. Added some more examples
+ and explination to the 'Keywords' snack. (Stevan)
+
+ * Moose
+ - added "FEATURE REQUESTS" section to the Moose docs
+ to properly direct people (Stevan) (RT #34333)
+ * Moose::Cookbook::Style
+ - added general Moose "style guide" of sorts to the
+ cookbook (nothingmuch) (RT #34335)
0.51 Thurs. Jun 26, 2008
* Moose::Role
* Moose::Meta::TypeConstraint
* Moose::Meta::TypeCoercion
- Attempt to work around the ??{ } vs. threads issue
+ (not yet fixed)
- Some null_constraint optimizations
0.50 Thurs. Jun 11, 2008
lib/Moose/Cookbook/Recipe6.pod
lib/Moose/Cookbook/Recipe7.pod
lib/Moose/Cookbook/Recipe9.pod
-lib/Moose/Cookbook/Snack/ArrayRef.pod
-lib/Moose/Cookbook/Snack/BUILD.pod
-lib/Moose/Cookbook/Snack/HashRef.pod
lib/Moose/Cookbook/Snack/Keywords.pod
-lib/Moose/Cookbook/Snack/Perl5ObjsVsMooseObjs.pod
lib/Moose/Cookbook/Snack/Types.pod
lib/Moose/Cookbook/WTF.pod
lib/Moose/Meta/Attribute.pm
use strict;
use warnings;
-use inc::Module::Install 0.75;
+use inc::Module::Install;
name 'Moose';
all_from 'lib/Moose.pm';
exception. If you find a bug please either email me, or add the bug
to cpan-RT.
+=head1 FEATURE REQUESTS
+
+We are very strict about what features we add to the Moose core, especially
+the user-visible features. Instead we have made sure that the underlying
+meta-system of Moose is as extensible as possible so that you can add your
+own features easily. That said, occasionally there is a feature needed in the
+meta-system to support your planned extension, in which case you should
+either email the mailing list or join us on irc at #moose to discuss.
+
=head1 AUTHOR
Stevan Little E<lt>stevan@iinteractive.comE<gt>
+++ /dev/null
-
-=pod
-
-=head1 NAME
-
-Moose::Cookbook::Snack::ArrayRef - Using the ArrayRef type constraint
-
-=head1 SYNOPSIS
-
- package Fruit;
- use Moose;
-
- has 'name' => (is => 'rw', required => 1);
- has 'species' => (is => 'rw', required => 1);
-
- package ProduceStore;
- use Moose;
- use Moose::Util::TypeConstraints;
-
- has 'fruit_aisle' => (isa => 'ArrayRef[Fruit]', is => 'rw');
-
- package main;
-
- # we need something to put in the fruit aisle
- my $orange = Fruit->new(name => 'orange', species => 'C. sinensis');
- my $apple = Fruit->new(name => 'apple', species => 'M. domestica');
- my @fruit = ($apple, $orange);
- my $store = ProduceStore->new(fruit_aisle => \@fruit);
-
-=head1 DESCRIPTION
-
-The ArrayRef type constraint is used to store a reference to a Perl list or
-array variable as an attribute of a Moose object.
-
-=head2 Disclaimer
-
-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 array references in order to
-help keep your Moose objects nice and encapsulated.
-
-=head2 Assigning arrays to an ArrayRef attribute
-
-Once a Moose-based object with an C<ArrayRef> attribute has been created, you
-can pass an array (by reference) to that object attribute using that
-attribute's accessor. This is how we assign the apple and orange to the
-store's C<fruit_aisle> C<ArrayRef> attribute, we pass an array containing both
-objects by reference to the C<fruit_aisle> attribute:
-
- my @fruit = ($apple, $orange);
- my $store = ProduceStore->new(fruit_aisle => \@fruit);
-
-Or you can pass an anonymous array to the C<ArrayRef> attribute as well. If
-you created two new objects, C<$grape> and C<$tomato>, and assigned them to
-the C<ArrayRef>, they would replace the apple and the orange in the store's
-fruit aisle:
-
- $store->fruit_aisle( [$grape, $tomato] );
-
-Our C<fruit_aisle> C<ArrayRef> is parameterized, meaning, that the
-C<fruit_aisle> C<ArrayRef> can contain nothing but C<Fruit> objects as array
-values. If you try to pass in a reference to a array using C<Str> objects as
-array values for example, Moose will complain:
-
- Attribute (fruit_aisle) does not pass the type constraint (ArrayRef[Str])
-
-=head2 Dumping the contents of an ArrayRef
-
-In order to dump the contents of a C<ArrayRef> object attribute, you must first
-de-reference the C<ArrayRef>, and then enumerate over it's keys. You can add
-this method for showing the store's inventory to the C<ProduceStore>
-object shown in the SYNOPSIS:
-
- sub show_inventory {
- my $self = shift;
- foreach my $item ( @{$self->fruit_aisle} ) {
- # ... access each Fruit object
- }
- }
-
-=head2 Assigning arrays to an ArrayRef will overwrite existing arrays
-
-Once you create an object containing a C<ArrayRef> attribute, if you assign a
-new array reference to that attribute, it will replace any existing array
-reference:
-
- # replace existing inventory
- my $grape = Fruit->new(name => 'grape', species => 'V. vinifera');
- my $tomato = Fruit->new(name => 'tomato', species => 'S. lycopersicum');
- $store->fruit_aisle( [$grape, $tomato] );
-
-=head2 Appending/Deleting values to/from an ArrayRef
-
-In order to append new elements to an array referred to by the C<ArrayRef>
-attribute, you will need to make a copy of the array first, add your new array
-elements, then assign your modified copy back to the C<ArrayRef> attribute:
-
- my @fruit_aisle_copy = @{$store->fruit_aisle};
- my $avocado = Fruit->new(name => 'avocado', species => 'P. americana');
- push(@fruit_aisle_copy, $avocado);
- $store->fruit_aisle( \@fruit_aisle_copy );
-
-And here's an example of deleting an object stored in an ArrayRef:
-
- my @fruit_aisle_copy = @{$store->fruit_aisle};
- # new array to hold the fruit objects that won't be deleted
- my @reworked_fruit_aisle;
- for my $fruit_obj ( @fruit_aisle_copy ) {
- if ( $fruit_obj->name ne 'tomato' ) {
- push(@reworked_fruit_aisle, $fruit_obj);
- }
- }
- $store->fruit_aisle( \@reworked_fruit_aisle );
-
-Putting the above code into their own object methods would make appending to or deleting from an C<ArrayRef> a trivial operation.
-
-=head2 Clearing an ArrayRef
-
-Assigning C<undef> to clear an C<ArrayRef> will not work because the attribute
-was originally defined with a type constraint, meaning that attribute must have
-0 or more of that type of value to be valid. C<undef> in Perl is not a value,
-so it won't work for clearing the C<ArrayRef>.
-
-If you assign an empty anonymous hash to a C<ArrayRef> attribute, this will
-clear out that attribute yet still satisfy the type constraint.
-
- # this clears the ArrayRef
- $store->fruit_aisle( [ ] );
-
-=head1 SEE ALSO
-
-=over 4
-
-=item L<Moose::Cookbook::Recipe4> - Subtypes, and modeling a simple Company
-class hierarchy
-
-=item L<Moose::Cookbook::Snack::Types> - Snippets of code for using Types and
-Type Constraints
-
-=item L<Moose::Util::TypeConstraints> - Type constraints that Moose can use
-and the tools to extend them or create your own.
-
-=item L<Moose::Autobox> - Autoboxed wrappers for Native Perl datatypes
-
-=item L<MooseX::AttributeHelpers> - Extends attribute interfaces
-
-=back
-
-=head1 AUTHOR
-
-Brian Manning <elspicyjack at gmail dot com>
-
-=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
+++ /dev/null
-
-=pod
-
-=head1 NAME
-
-Moose::Cookbook::Snack::BUILD - Custom initialization methods for Moose objects
-
-=head1 SYNOPSIS
-
- package Build::Demo;
- use Moose;
-
- # once the object has been created, don't allow
- # changes to 'example_file'
- has 'example_file' => (is => 'ro', required => 1);
-
- sub BUILD {
- my $self = shift;
- # create the object only if the 'example_file' exists
- if (-e $self->example_file) {
- return $self;
- }
- else {
- die('ERROR: file _' . $self->example_file . '_ does not exist');
- }
- }
-
- package main;
- use Moose;
-
- # the name of this script, which works
- my $first_test = Build::Demo->new(example_file => $0);
- # this should fail (unless there's a file named 'foo'
- # in the current directory)
- my $second_test = Build::Demo->new(example_file => 'foo');
-
-=head1 DESCRIPTION
-
-The C<BUILD()> method allows you to write your own initialization methods for
-your Moose objects.
-
-=head2 Creating new objects in Perl and Moose
-
-By convention, most objects in Perl are created by calling a C<new()> method
-inside that object:
-
- package My::Perl::Class;
-
- sub new {
- # object blessing and initialization code goes here...
- }
-
- package main;
- my $object = My::Perl::Class->new();
-
-Moose is no different in this respect. However, since Moose handles the
-C<new()> method for you, how do you change the default behaivor of the
-C<new()> method in Moose? This is what the C<BUILD()> method was designed
-for.
-
- package My::Moose::Class;
-
- sub BUILD {
- # object initialization code goes here...
- }
-
- package main;
- my $object = My::Moose::Class->new();
-
-=head2 Why would you want a custom constructor?
-
-If your object needs to verify some behaivor or internal state before it is
-created, a good time to do that is when the object is being created. Why
-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
-run it.
-
-=head2 What is 'BUILDALL'?
-
-(Taken from L<Moose::Object>) The C<BUILDALL> method will call every BUILD
-method in the inheritance hierarchy, and pass it a hash-ref of the the
-C<%params> passed to the C<new()> method.
-
-=head1 SEE ALSO
-
-=over 4
-
-=item L<Moose::Object> - The base object for Moose (BUILDALL)
-
-=item L<Moose::Cookbook::FAQ> - Frequently asked questions about Moose
-(How do I write custom constructors with Moose?)
-
-=item L<Moose::Cookbook::Recipe4> - Subtypes, and modeling a simple
-Company class heirarchy (Example usage of BUILD in action)
-
-=item L<Moose::Cookbook::WTF> - For when things go wrong with Moose
-('Roles' section describes BUILD/BUILDALL)
-
-=back
-
-=head1 AUTHOR
-
-Brian Manning <elspicyjack at gmail dot com>
-
-=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
+++ /dev/null
-
-=pod
-
-=head1 NAME
-
-Moose::Cookbook::Snack::HashRef - Using the HashRef type constraint
-
-=head1 SYNOPSIS
-
- package Fruit;
- use Moose;
-
- has 'species' => ( is => 'rw', required => 1 );
-
- package ProduceStore;
- use Moose;
- use Moose::Util::TypeConstraints;
-
- has 'fruit_aisle' => ( is => 'rw', isa => 'HashRef[Fruit]' );
-
- package main;
- use Moose;
-
- # we need something to put in the fruit aisle
- my $orange = Fruit->new( species => 'C. sinensis' );
- my $apple = Fruit->new( species => 'M. domestica' );
- my %fruit = ( orange => $orange, apple => $apple );
- my $store = ProduceStore->new( fruit_aisle => \%fruit );
-
-=head1 DESCRIPTION
-
-The HashRef type constraint is used to store a reference to a Perl hash
-variable as an attribute of a Moose object.
-
-=head2 Disclaimer
-
-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. 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
-
-Once a Moose-based object with a C<HashRef> attribute has been created, you
-can pass a hash (by reference) to that attribute using that attribute's
-accessor. This is how we assign the apple and orange to the store's
-C<fruit_aisle> C<HashRef> attribute, we pass a hash containing both objects by
-reference to the C<fruit_aisle> attribute:
-
- my %fruit = ( orange => $orange, apple => $apple );
- my $store = ProduceStore->new( fruit_aisle => \%fruit );
-
-Or you can pass an anonymous hash to the C<HashRef> attribute as well. If you
-created two new objects, C<$grape> and C<$tomato>, and assigned them to the
-C<HashRef>, they would replace the apple and the orange in the store's fruit
-aisle:
-
- $store->fruit_aisle( { grape => $grape, tomato => $tomato } );
-
-Our C<fruit_aisle> C<HashRef> example is parameterized, meaning, that the
-C<fruit_aisle> C<HashRef> can contain nothing but C<Fruit> objects as hash
-values. If you try to pass in a reference to a hash using C<Int> objects as
-hash values for example, Moose will complain:
-
- Attribute (fruit_aisle) does not pass the type constraint (HashRef[Int])
-
-=head2 Dumping the contents of the HashRef
-
-In order to dump the contents of a C<HashRef> object attribute, you must first
-de-reference the C<HashRef>, and then enumerate over it's keys.
-
- foreach my $item ( keys(%{$self->fruit_aisle}) ) {
- my $fruit = $self->{fruit_aisle}{$item};
- print "Item: $item, type: " . $fruit->meta->name
- . " species: " . $fruit->species . "\n";
- }
-
-If the above de-referencing of the C<fruit_aisle> C<HashRef> is a little too
-noisy, you could create a copy of it, and then enumerate over that copy:
-
- my %fruit_aisle_copy = %{$self->fruit_aisle};
- foreach my $item ( keys(%fruit_aisle_copy) ) {
- my $fruit = $fruit_aisle_copy{$item};
- print "Item: $item, type: " . $fruit->meta->name
- . " species: " . $fruit->species . "\n";
- }
-
-=head2 Assigning to a HashRef attribute will overwrite
-
-Once you create an object containing a C<HashRef> attribute, if you assign a
-new hash reference to that attribute, it will replace any existing hash
-reference:
-
- # this replaces the existing HashRef contents
- my $grape = Fruit->new( species => 'V. vinifera' );
- my $tomato = Fruit->new( species => 'S. lycopersicum');
- $store->fruit_aisle( { grape => $grape, tomato => $tomato } );
-
-=head2 Appending/Deleting key/value pairs to a HashRef
-
-In order to append or delete key/value pairs to the hash referred to by the
-C<HashRef> attribute, you will need to make a copy of the hash first, add or
-delete the desired key/value pairs, then assign your modified copy back to the
-C<HashRef> attribute. Here's an example of appending new key/value pars:
-
- my %fruit_aisle_copy = %{$store->fruit_aisle};
- 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:
-
- # delete an attribute from the HashRef
- %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.
-
-=head2 Clearing the HashRef
-
-Assigning C<undef> to clear a C<HashRef> will not work because the attribute
-was originally defined with a type constraint, meaning that attribute must have
-0 or more of that type of value to be valid. B<undef> in Perl is not a value,
-so it won't work for clearing the C<HashRef>.
-
-If you assign an empty anonymous hash to a C<HashRef> attribute, this will
-clear out that attribute yet still satisfy the type constraint.
-
- # this clears the HashRef
- $store->fruit_aisle( { } );
-
-=head1 SEE ALSO
-
-=over 4
-
-=item L<Moose::Cookbook::Snack::Types> - Snippets of code for using Types and
-Type Constraints
-
-=item L<Moose::Util::TypeConstraints> - Type constraints that Moose can use
-and the tools to extend them or create your own.
-
-=item L<Moose::Autobox> - Autoboxed wrappers for Native Perl datatypes
-
-=item L<MooseX::AttributeHelpers> - Extends attribute interfaces
-
-=back
-
-=head1 AUTHOR
-
-Brian Manning <elspicyjack at gmail dot com>
-
-=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
Moose::Cookbook::Snack::Keywords - Restricted keywords in Moose
-=cut
-
=head1 DESCRIPTION
-There are several keywords exported in L<Moose> that cause clashes against
-any barewords such as attribute names, sub names, and globs.
-
+There are several keywords exported by L<Moose> that can cause clashes
+against other user-defined barewords. The following document provides
+a list of those keywords in a single place for easy reference.
=head2 The 'meta' keyword
While most of the reserved keywords collisions can be avoided, however
-I<meta> is the only one you B<cant> override. Do not attempt to override
-I<meta>.
+I<meta> is the only one you B<can not> override. Do not attempt to override
+I<meta>, it will break the Moose internals.
=head2 Moose Keywords
-If you are using Moose its best to avoid these keywords
+If you are using L<Moose> or L<Moose::Role> its best to avoid these
+keywords:
=over 4
=head2 Moose::Util::TypeConstraints Keywords
-If you are using Moose::Util::TypeConstraints its best to avoid
+If you are using L<Moose::Util::TypeConstraints> its best to avoid
these keywords
=over 4
=back
=head2 Avoiding collisions
-
+
=head3 Turning off Moose
-To remove the keywords Moose exports using no Moose at the bottom of your code
+To remove the keywords L<Moose> exports just add C<no Moose> at the bottom of
+your code, like so:
+
+ package Thing;
+ use Moose;
- package Thing;
- use Moose;
+ # code here
- # code here
+ no Moose;
- no Moose;
+This will un-export the keywords that L<Moose> originally exported. The same
+will also work for L<Moose::Role> and L<Moose::Util::TypeConstraints>. It is
+general L<Moose> policy that this feature is used.
=head3 Sub::Exporter
-The L<Sub::Exporter> module can rename keywords
+L<Moose>, L<Moose::Role> and L<Moose::Util::TypeConstraints> all use
+L<Sub::Exporter> to handle all their exporting needs. This means that all the
+features that L<Sub::Exporter> provides are also available to them.
- package LOL::Cat;
- use Moose 'has' => { -as => 'i_can_haz' };
+For instance, with L<Sub::Exporter> you can rename keywords, like so:
- i_can_haz 'cheeseburger' => (
- is => 'rw',
- trigger => sub { print "NOM NOM" }
- );
+ package LOL::Cat;
+ use Moose 'has' => { -as => 'i_can_haz' };
+
+ i_can_haz 'cheeseburger' => (
+ is => 'rw',
+ trigger => sub { print "NOM NOM" }
+ );
+
+ LOL::Cat->new->cheeseburger('KTHNXBYE');
- LOL::Cat->new->cheeseburger('KTHNXBYE');;
+See the L<Sub::Exporter> docs for more information.
=head3 namespace::clean
-You can use L<namespace::clean> to clean up the namespace
+You can also use L<namespace::clean> to clean up your namespace, but you must
+be careful not to remove C<meta> with this. Here is an example of that usage:
+
+ package Foo;
+ use Moose;
+ use namespace::clean -except => 'meta';
+ # ...
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<Moose>
-=head1 AUTHOR AND COPYRIGHT
+=item L<Moose::Role>
+
+=item L<Moose::Utils::TypeConstraints>
+
+=item L<Sub::Exporter>
+
+=item L<namespace::clean>
+
+=back
+
+=head1 AUTHOR
John Goulah C<E<lt>jgoulah@cpan.org<gt>>
-=head1 LICENSE
+Stevan Little E<lt>stevan@iinteractive.comE<gt>
+
+=head1 COPYRIGHT AND LICENSE
+
+Copyright 2006-2008 by Infinity Interactive, Inc.
+
+L<http://www.iinteractive.com>
-This program is free software; you can redistribute it and/or modify
-it under the same terms as perl itself.
+This library is free software; you can redistribute it and/or modify
+it under the same terms as Perl itself.
=cut
+++ /dev/null
-
-=pod
-
-=head1 NAME
-
-Moose::Cookbook::Snack::Perl5ObjsVsMooseObjs - Short comparison between Perl 5
-objects and Moose objects
-
-=head1 SYNOPSIS
-
- package Moose::Demo;
- use Moose; # automagically sets 'strict' and 'warnings'
-
- has 'script_name' => ( is => 'rw', required => 1);
-
- package main;
-
- # '$0' is the name of this script, set automatically by Perl
- my $demo = Moose::Demo->new( script_name => $0 );
-
- print "My name is " . $demo->script_name . "\n";
- print "I am a " . $demo->meta->name . " type of object\n";
-
-=head1 DESCRIPTION
-
-So what's the big stink about Moose? Perl 5 comes with objects and object
-oriented programming already. Given the above Moose code, what would similar
-code look like in the existing Perl 5 object-oriented style of programming?
-Let's take a look and find out...
-
-=head2 Perl 5 OO Example
-
- # Perl 5 Object, as taught by the 'perltoot' POD page
- package Perl5::Demo;
- use strict;
- use warnings;
-
-
- sub new {
- my $class = shift;
- # assign the rest of the method arguments to a temp hash
- my %args = @_;
-
- # create the object out of a blessed hash reference
- my $self = bless ( {}, ref($class) || $class );
- # create the script_name attribute
- $self->{script_name} = undef;
-
- # verify that the user passed in the 'script_name' attribute
- if ( exists $args{script_name} ) {
- $self->script_name($args{script_name});
- }
- else {
- die "ERROR: can't create object without 'script_name' ";
- }
-
- # return the object reference back to the caller
- return $self;
- }
-
- sub script_name {
- my $self = shift;
- # check for arguments; use the argument
- # if passed in, otherwise return the
- # existing value (if any)
- if (@_) {
- $self->{script_name} = shift;
- }
- return $self->{script_name};
- }
-
- package main;
- use strict;
- use warnings;
-
- my $demo = Perl5::Demo->new( script_name => $0 );
-
- print "My name is " . $demo->script_name . "\n";
- print "I am a " . ref($demo) . " type of object\n";
-
-Looks more complex, right? Moose does a lot of the labor when working with
-Perl objects, so that you don't have to. What are some of the specific
-differences between Moose and Perl 5 Objects?
-
-=head3 Difference #1 - declaration of object attributes
-
-Both the Moose and Perl 5 objects have one attribute, C<script_name>. It's a
-good programming practice to always validate user input, so we have the Perl 5
-object check to make sure that the user passes in the C<script_name> attribute
-to it when the object is created. The Moose object automatically checks this
-for us when we set C<required =E<gt> 1> in the C<has> function for the Moose
-object.
-
-In more advanced Moose usage, you can use something called 'type constraints'
-when creating your Moose objects. Type constraints are used to validate what
-the user passes in when setting Moose object attributes. If the user passes
-in a type of data that Moose is not expecting, then the type constraints in
-Moose (specifically, the L<Moose::Util::TypeConstraint> module) will let the
-user know this in no uncertain terms. Type constraints in Moose can be as
-simple as strings or numbers, or as complex as other Moose objects.
-
-=head3 Difference #2 - strict and warning pragmas
-
-Moose sets the 'strict' and 'warnings' pragmas for you automatically. We have
-to do this for ourselves in the Perl 5 example.
-
-=head3 Difference #3 - Determining an object's class name
-
-The C<ref()> function in Perl 5 is how you determine an object's class name.
-The proper way to do this with Moose is C<$object-E<gt>meta-E<gt>name>;
-
- # an object's class name in Perl 5 OO
- print "I am a " . ref($demo) . " type of object\n";
-
- # an object's class name in Moose
- print "I am a " . $demo->meta->name . " type of object\n";
-
-Moose builds on C<Class::MOP> to provide a rich introspection API that
-goes way beyond just getting the class name. Check out the
-C<Class::MOP> documentation for more details.
-
-=head3 Difference #4 - Assigning values to Moose object attributes
-
-When you wish to assign a value directly to an object attribute for a Perl 5
-object, you can either create an object method that handles the value for you;
-
- package Perl5Object;
- sub set_x { # some code here that sets 'x' }
- package main;
- # later on...
- $self->set_x(0);
-
-or you can assign the value directly to the Perl 5 object attribute like this:
-
- $self->{x} = 0;
-
-Moose creates object methods for handling attributes for you, as long as you
-specified C<is =E<gt> rw> for each C<has> statement inside the object
-declaration. This is mentioned in L<Moose::Cookbook::WTF>, in the section
-labeld B<Accessors>, but briefly:
-
- package MooseObject;
- has 'x' => (is => 'rw');
- package main;
- # later on...
- $self->x(0);
-
-The syntax shown for the Perl 5 object (C<$self-E<gt>{x} = 0>) will
-also work on the Moose object, as Moose objects are, by default,
-blessed hashes just like the average Perl object is. However, if you
-access the object's hash reference directly via the latter syntax you
-will have several problems.
-
-First, Moose will no longer be able to enforce attribute constraints,
-such as read-only or type constraints. Second, you've broken that
-object's encapsulation, and encapsulation is one of the reasons you
-want to use objects in the first place, right?
-
-=head1 SEE ALSO
-
-=over 4
-
-=item L<Moose::Cookbook::Recipe1> - The 'Point' object example
-
-=item L<Moose::Util::TypeConstraints> - Type constraints that Moose can use
-and the tools to extend them or create your own.
-
-=item L<Moose::Cookbook::WTF> - For when things go wrong with Moose
-
-=back
-
-=head1 AUTHOR
-
-Brian Manning <elspicyjack at gmail dot com>
-
-=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
This will improve your code and also share the benefit with others.
+=head1 AUTHOR
+
+Yuval (nothingmuch) Kogman
+
+=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
projects / gitmo/Moose.git / commitdiff