=head1 DATE
-This document was created in February, 2011.
+This document was created in February, 2011, and the last major
+revision was in February, 2013.
+
+If you are reading this in the future then it's possible that the state
+of the art has changed. We recommend you start by reading the perlootut
+document in the latest stable release of Perl, rather than this
+version.
=head1 DESCRIPTION
The methods associated with a file might include C<rename()> and
C<write()>.
-In Perl most objects are hash references, but the OO systems we
-recommend keep you from having to worry about this. In practice, it's
-best to consider an object's internal data structure opaque.
+In Perl most objects are hashes, but the OO systems we recommend keep
+you from having to worry about this. In practice, it's best to consider
+an object's internal data structure opaque.
=head2 Class
=head3 Blessing
-As we said earlier, most Perl objects are hash references, but an
-object can be a reference to any Perl data type (scalar, array, etc.).
-Turning a plain reference into an object is done by B<blessing> that
-reference using Perl's C<bless> function.
+As we said earlier, most Perl objects are hashes, but an object can be
+an instance of any Perl data type (scalar, array, etc.). Turning a
+plain data structure into an object is done by B<blessing> that data
+structure using Perl's C<bless> function.
While we strongly suggest you don't build your objects from scratch,
-you should know the term B<bless>. A B<blessed> reference is an object.
-We sometimes say that an object has been "blessed into a class".
+you should know the term B<bless>. A B<blessed> data structure (aka "a
+referent") is an object. We sometimes say that an object has been
+"blessed into a class".
-Once a reference has been blessed, the C<blessed> function from the
+Once a referent has been blessed, the C<blessed> function from the
L<Scalar::Util> core module can tell us its class name. This subroutine
returns an object's class when passed an object, and false otherwise.
You already learned that a B<method> is a subroutine that operates on
an object. You can think of a method as the things that an object can
-I<do>.
+I<do>. If an object is a noun, then methods are its verbs (save, print,
+open).
In Perl, methods are simply subroutines that live in a class's package.
Methods are always written to receive the object as their first
print "This file is at ", $self->path, "\n";
}
- $larry->print_path;
+ $file->print_info;
# The file is at /etc/hostname
What makes a method special is I<how it's called>. The arrow operator
print $prefix, ", ", $self->path, "\n";
}
- $larry->print_info("The file is located at ");
+ $file->print_info("The file is located at ");
# The file is located at /etc/hostname
=head2 Attributes
has a path. Attributes are sometimes called B<properties>.
Perl has no special syntax for attributes. Under the hood, attributes
-are often stored as keys in the object's hash reference, but don't
+are often stored as keys in the object's underlying hash, but don't
worry about this.
We recommend that you only access attributes via B<accessor> methods.
=head2 Inheritance
B<Inheritance> lets you create a specialized version of an existing
-class. Inheritance lets the new class to reuse the methods and
-attributes of another class.
+class. Inheritance lets the new class reuse the methods and attributes
+of another class.
For example, we could create an C<File::MP3> class which B<inherits>
from C<File>. An C<File::MP3> B<is-a> I<more specific> type of C<File>.
All mp3 files are files, but not all files are mp3 files.
We often refer to inheritance relationships as B<parent-child> or
-C<superclass/subclass> relationships. Sometimes we say that the child
+C<superclass>/C<subclass> relationships. Sometimes we say that the child
has an B<is-a> relationship with its parent class.
C<File> is a B<superclass> of C<File::MP3>, and C<File::MP3> is a
violating encapsulation, but a good API can minimize the need to do
this.
-We mentioned earlier that most Perl objects are implemented as hash
-references under the hood. The principle of encapsulation tells us that
-we should not rely on this. Instead, we should use accessor methods to
-access the data in that hash reference. The object systems that we
-recommend below all automate the generation of accessor methods. If you
-use one of them, you should never have to access the object as a hash
-reference directly.
+We mentioned earlier that most Perl objects are implemented as hashes
+under the hood. The principle of encapsulation tells us that we should
+not rely on this. Instead, we should use accessor methods to access the
+data in that hash. The object systems that we recommend below all
+automate the generation of accessor methods. If you use one of them,
+you should never have to access the object as a hash directly.
=head2 Composition
Here is our C<File> class using C<Moose>:
-
-Here's a simple but complete C<Moose> class:
-
package File;
use Moose;
compiler, or if having I<any> dependencies is a problem, then C<Moose>
may not be right for you.
-=head3 Mouse
+=head3 Moo
If you try C<Moose> and find that one of these issues is preventing you
-from using C<Moose>, we encourage you to consider L<Mouse> next.
-C<Mouse> implements a subset of C<Moose>'s functionality in a simpler
-package. For all features that it does implement, the end-user API is
-I<identical> to C<Moose>, meaning you can switch from C<Mouse> to
+from using C<Moose>, we encourage you to consider L<Moo> next. C<Moo>
+implements a subset of C<Moose>'s functionality in a simpler package.
+For most features that it does implement, the end-user API is
+I<identical> to C<Moose>, meaning you can switch from C<Moo> to
C<Moose> quite easily.
-C<Mouse> does not implement most of C<Moose>'s introspection API, so
-it's often faster when loading your modules. Additionally, all of its
-I<required> dependencies ship with the Perl core, and it can run
-without a compiler. If you do have a compiler, C<Mouse> will use it to
-compile some of its code for a speed boost.
+C<Moo> does not implement most of C<Moose>'s introspection API, so it's
+often faster when loading your modules. Additionally, none of its
+dependencies require XS, so it can be installed on machines without a
+compiler.
-Finally, it ships with a C<Mouse::Tiny> module that takes most of
-C<Mouse>'s features and bundles them up in a single module file. You
-can copy this module file into your application's library directory for
-easy bundling.
+One of C<Moo>'s most compelling features is its interoperability with
+C<Moose>. When someone tries to use C<Moose>'s introspection API on a
+C<Moo> class or role, it is transparently inflated into a C<Moose>
+class or role. This makes it easier to incorporate C<Moo>-using code
+into a C<Moose> code base and vice versa.
-The C<Moose> authors hope that one day C<Mouse> can be made obsolete by
+For example, a C<Moose> class can subclass a C<Moo> class using
+C<extends> or consume a C<Moo> role using C<with>.
+
+The C<Moose> authors hope that one day C<Moo> can be made obsolete by
improving C<Moose> enough, but for now it provides a worthwhile
alternative to C<Moose>.
Like C<Moose>, C<Class::Accessor> generates accessor methods and a
constructor for your class.
-=head2 Object::Tiny
+=head2 Class::Tiny
-Finally, we have L<Object::Tiny>. This module truly lives up to its
+Finally, we have L<Class::Tiny>. This module truly lives up to its
name. It has an incredibly minimal API and absolutely no dependencies
-(core or not). Still, we think it's a lot easier to use than writing
+on any recent Perl. Still, we think it's a lot easier to use than writing
your own OO code from scratch.
Here's our C<File> class once more:
package File;
- use Object::Tiny qw( path content last_mod_time );
+ use Class::Tiny qw( path content last_mod_time );
sub print_info {
my $self = shift;
That's it!
-With C<Object::Tiny>, all accessors are read-only. It generates a
+With C<Class::Tiny>, all accessors are read-write. It generates a
constructor for you, as well as the accessors you define.
+You can also use L<Class::Tiny::Antlers> for C<Moose>-like syntax.
+
=head2 Role::Tiny
As we mentioned before, roles provide an alternative to inheritance,
system, but in a much smaller package. Most notably, it doesn't support
any sort of attribute declaration, so you have to do that by hand.
Still, it's useful, and works well with C<Class::Accessor> and
-C<Object::Tiny>
+C<Class::Tiny>
=head2 OO System Summary
=item * L<Moose>
C<Moose> is the maximal option. It has a lot of features, a big
-ecosystem, and a thriving user base. We also covered L<Mouse> briefly.
-C<Mouse> is C<Moose> lite, and a reasonable alternative when Moose
+ecosystem, and a thriving user base. We also covered L<Moo> briefly.
+C<Moo> is C<Moose> lite, and a reasonable alternative when Moose
doesn't work for your application.
=item * L<Class::Accessor>
compatibility mode which makes moving from C<Class::Accessor> to
C<Moose> easy.
-=item * L<Object::Tiny>
+=item * L<Class::Tiny>
-C<Object::Tiny> is the absolute minimal option. It has no dependencies,
+C<Class::Tiny> is the absolute minimal option. It has no dependencies,
and almost no syntax to learn. It's a good option for a super minimal
environment and for throwing something together quickly without having
to worry about details.
=item * L<Role::Tiny>
-Use C<Role::Tiny> with C<Class::Accessor> or C<Object::Tiny> if you
+Use C<Role::Tiny> with C<Class::Accessor> or C<Class::Tiny> if you
find yourself considering multiple inheritance. If you go with
C<Moose>, it comes with its own role implementation.
=head1 CONCLUSION
-As we said before, Perl's minimal OO system has lead to a flourishing
-of OO systems on CPAN. While you can still drop down to the bare metal
-and write your classes by hand, there's really no reason to do that in
-2011.
+As we said before, Perl's minimal OO system has led to a profusion of
+OO systems on CPAN. While you can still drop down to the bare metal and
+write your classes by hand, there's really no reason to do that with
+modern Perl.
-For small systems, L<Object::Tiny> and L<Class::Accessor> both provide
+For small systems, L<Class::Tiny> and L<Class::Accessor> both provide
minimal object systems that take care of basic boilerplate for you.
For bigger projects, L<Moose> provides a rich set of features that will
let you focus on implementing your business logic.
We encourage you to play with and evaluate L<Moose>,
-L<Class::Accessor>, and L<Object::Tiny> to see which OO system is right
+L<Class::Accessor>, and L<Class::Tiny> to see which OO system is right
for you.
=cut
https://perl5.git.perl.org / perl5.git / blobdiff