=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
dependencies require XS, so it can be installed on machines without a
compiler.
+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.
+
+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
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.
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