use strict;
use warnings;
-our $VERSION = '0.56';
+use 5.008;
+
+our $VERSION = '0.57';
+$VERSION = eval $VERSION;
our $AUTHORITY = 'cpan:STEVAN';
use Scalar::Util 'blessed';
use Moose::Exporter;
-use Class::MOP 0.64;
+use Class::MOP 0.65;
use Moose::Meta::Class;
use Moose::Meta::TypeConstraint;
use Moose::Meta::Role::Application::ToClass;
use Moose::Meta::Role::Application::ToRole;
use Moose::Meta::Role::Application::ToInstance;
-use Moose::Meta::Role::Application::ToMetaclassInstance;
use Moose::Util::TypeConstraints;
use Moose::Util ();
+sub throw_error {
+ # FIXME This
+ shift;
+ goto \&confess
+}
+
sub extends {
my $class = shift;
# this checks the metaclass to make sure
# it is correct, sometimes it can get out
# of sync when the classes are being built
- my $meta = Class::MOP::Class->initialize($class)->_fix_metaclass_incompatability(@supers);
+ my $meta = Moose::Meta::Class->initialize($class)->_fix_metaclass_incompatability(@supers);
$meta->superclasses(@supers);
}
my %args = @_;
my $class = $args{for_class}
- or confess "Cannot call init_meta without specifying a for_class";
+ or Moose->throw_error("Cannot call init_meta without specifying a for_class");
my $base_class = $args{base_class} || 'Moose::Object';
my $metaclass = $args{metaclass} || 'Moose::Meta::Class';
- confess
- "The Metaclass $metaclass must be a subclass of Moose::Meta::Class."
+ Moose->throw_error("The Metaclass $metaclass must be a subclass of Moose::Meta::Class.")
unless $metaclass->isa('Moose::Meta::Class');
# make a subtype for each Moose class
unless find_type_constraint($class);
my $meta;
+
+ if ( $meta = Class::MOP::get_metaclass_by_name($class) ) {
+ unless ( $meta->isa("Moose::Meta::Class") ) {
+ Moose->throw_error("$class already has a metaclass, but it does not inherit $metaclass ($meta)");
+ }
+ } else {
+ # no metaclass, no 'meta' method
+
+ # now we check whether our ancestors have metaclass, and if so borrow that
+ my ( undef, @isa ) = @{ $class->mro::get_linear_isa };
+
+ foreach my $ancestor ( @isa ) {
+ my $ancestor_meta = Class::MOP::get_metaclass_by_name($ancestor) || next;
+
+ my $ancestor_meta_class = ($ancestor_meta->is_immutable
+ ? $ancestor_meta->get_mutable_metaclass_name
+ : ref($ancestor_meta));
+
+ # if we have an ancestor metaclass that inherits $metaclass, we use
+ # that. This is like _fix_metaclass_incompatability, but we can do it now.
+
+ # the case of having an ancestry is not very common, but arises in
+ # e.g. Reaction
+ unless ( $metaclass->isa( $ancestor_meta_class ) ) {
+ if ( $ancestor_meta_class->isa($metaclass) ) {
+ $metaclass = $ancestor_meta_class;
+ }
+ }
+ }
+
+ $meta = $metaclass->initialize($class);
+ }
+
if ( $class->can('meta') ) {
+ # check 'meta' method
+
+ # it may be inherited
+
# NOTE:
# this is the case where the metaclass pragma
# was used before the 'use Moose' statement to
# override a specific class
- $meta = Class::MOP::Class->initialize($class);
- ( blessed($meta) && $meta->isa('Moose::Meta::Class') )
- || confess "You already have a &meta function, but it does not return a Moose::Meta::Class";
+ my $method_meta = $class->meta;
+
+ ( blessed($method_meta) && $method_meta->isa('Moose::Meta::Class') )
+ || Moose->throw_error("$class already has a &meta function, but it does not return a Moose::Meta::Class ($meta)");
+
+ $meta = $method_meta;
}
- else {
- # NOTE:
- # this is broken currently, we actually need
- # to allow the possiblity of an inherited
- # meta, which will not be visible until the
- # user 'extends' first. This needs to have
- # more intelligence to it
- $meta = $metaclass->initialize($class);
+
+ unless ( $meta->has_method("meta") ) { # don't overwrite
+ # also check for inherited non moose 'meta' method?
+ # FIXME also skip this if the user requested by passing an option
$meta->add_method(
'meta' => sub {
# re-initialize so it inherits properly
- $metaclass->initialize( blessed( $_[0] ) || $_[0] );
+ $metaclass->initialize( ref($_[0]) || $_[0] );
}
);
}
$meta->superclasses($base_class)
unless $meta->superclasses();
-
return $meta;
}
Moose::Meta::Role::Application::ToClass
Moose::Meta::Role::Application::ToRole
Moose::Meta::Role::Application::ToInstance
- Moose::Meta::Role::Application::ToMetaclassInstance
));
1;
The main goal of Moose is to make Perl 5 Object Oriented programming
easier, more consistent and less tedious. With Moose you can to think
-more about what you want to do and less about the mechanics of OOP.
+more about what you want to do and less about the mechanics of OOP.
-Additionally, Moose is built on top of L<Class::MOP>, which is a
-metaclass system for Perl 5. This means that Moose not only makes
-building normal Perl 5 objects better, but it provides the power of
-metaclass programming as well.
+Additionally, Moose is built on top of L<Class::MOP>, which is a
+metaclass system for Perl 5. This means that Moose not only makes
+building normal Perl 5 objects better, but it provides the power of
+metaclass programming as well.
=head2 New to Moose?
-If you're new to Moose, the best place to start is the
-L<Moose::Cookbook>. The recipes on Moose basics will get you up to
-speed with many of Moose's features quickly. Once you have an idea of
-what Moose can do, you can use the API documentation to get more
-detail on features which interest you.
+If you're new to Moose, the best place to start is the L<Moose::Intro>
+docs, followed by the L<Moose::Cookbook>. The intro will show you what
+Moose is, and how it makes Perl 5 OO better.
+
+The cookbook recipes on Moose basics will get you up to speed with
+many of Moose's features quickly. Once you have an idea of what Moose
+can do, you can use the API documentation to get more detail on
+features which interest you.
=head2 Moose Extensions
=head1 EXTENDING AND EMBEDDING MOOSE
-Moose also offers some options for extending or embedding it into your
-own framework. There are several things you might want to do as part
-of such a framework. First, you probably want to export Moose's sugar
-functions (C<has>, C<extends>, etc) for users of the
-framework. Second, you may want to provide additional sugar of your
-own. Third, you may want to provide your own object base class instead
-of L<Moose::Object>, and/or your own metaclass class instead of
-L<Moose::Meta::Class>.
-
-The exporting needs can be asily satisfied by using
-L<Moose::Exporter>, which is what C<Moose.pm> itself uses for
-exporting. L<Moose::Exporter> lets you "export like Moose".
-
-If you define an C<init_meta> method in a module that uses
-L<Moose::Exporter>, then this method will be called I<before>
-C<Moose.pm>'s own C<init_meta>. This gives you a chance to provide an
-alternate object base class or metaclass class.
-
-Here is a simple example:
-
- package MyFramework;
-
- use strict;
- use warnings;
-
- use Moose (); # no need to get Moose's exports
- use Moose::Exporter;
-
- Moose::Exporter->setup_import_methods( also => 'Moose' );
-
- sub init_meta {
- shift;
- return Moose->init_meta( @_, base_class => 'MyFramework::Base' );
- }
-
-In this example, any class that includes C<use MyFramework> will get
-all of C<Moose.pm>'s sugar functions, and will have their superclass
-set to C<MyFramework::Base>.
-
-Additionally, that class can include C<no MyFramework> to unimport
+To learn more about extending Moose, we recommend checking out the
+"Extending" recipes in the L<Moose::Cookbook>, starting with
+L<Moose::Cookbook::Extending::Recipe1>, which provides an overview of
+all the different ways you might extend Moose.
=head2 B<< Moose->init_meta(for_class => $class, base_class => $baseclass, metaclass => $metaclass) >>
sanely. It handles getting the exported functions into the right place
for you.
+=head2 throw_error
+
+An alias for C<confess>, used by internally by Moose.
+
=head1 CAVEATS
=over 4
their behavior is then easier to predict. Time will tell whether I am right or
not (UPDATE: so far so good).
-=item *
-
-It is important to note that we currently have no simple way of combining
-multiple extended versions of Moose (see L<EXTENDING AND EMBEDDING MOOSE> above),
-and that in many cases they will conflict with one another. We are working on
-developing a way around this issue, but in the meantime, you have been warned.
-
-=back
-
-=head1 JUSTIFICATION
-
-In case you are still asking yourself "Why do I need this?", then this
-section is for you. This used to be part of the main DESCRIPTION, but
-I think Moose no longer actually needs justification, so it is included
-(read: buried) here for those who are still not convinced.
-
-=over 4
-
-=item Another object system!?!?
-
-Yes, I know there has been an explosion recently of new ways to
-build objects in Perl 5, most of them based on inside-out objects
-and other such things. Moose is different because it is not a new
-object system for Perl 5, but instead an extension of the existing
-object system.
-
-Moose is built on top of L<Class::MOP>, which is a metaclass system
-for Perl 5. This means that Moose not only makes building normal
-Perl 5 objects better, but it also provides the power of metaclass
-programming.
-
-=item Is this for real? Or is this just an experiment?
-
-Moose is I<based> on the prototypes and experiments I did for the Perl 6
-meta-model. However, Moose is B<NOT> an experiment/prototype; it is for B<real>.
-
-=item Is this ready for use in production?
-
-Yes, I believe that it is.
-
-Moose has been used successfully in production environemnts by several people
-and companies (including the one I work for). There are Moose applications
-which have been in production with little or no issue now for well over two years.
-I consider it highly stable and we are commited to keeping it stable.
-
-Of course, in the end, you need to make this call yourself. If you have
-any questions or concerns, please feel free to email me, or even the list
-or just stop by #moose and ask away.
-
-=item Is Moose just Perl 6 in Perl 5?
-
-No. While Moose is very much inspired by Perl 6, it is not itself Perl 6.
-Instead, it is an OO system for Perl 5. I built Moose because I was tired of
-writing the same old boring Perl 5 OO code, and drooling over Perl 6 OO. So
-instead of switching to Ruby, I wrote Moose :)
-
-=item Wait, I<post> modern, I thought it was just I<modern>?
-
-So I was reading Larry Wall's talk from the 1999 Linux World entitled
-"Perl, the first postmodern computer language" in which he talks about how
-he picked the features for Perl because he thought they were cool and he
-threw out the ones that he thought sucked. This got me thinking about how
-we have done the same thing in Moose. For Moose, we have "borrowed" features
-from Perl 6, CLOS (LISP), Smalltalk, Java, BETA, OCaml, Ruby and more, and
-the bits we didn't like (cause they sucked) we tossed aside. So for this
-reason (and a few others) I have re-dubbed Moose a I<postmodern> object system.
-
-Nuff Said.
-
=back
=head1 ACKNOWLEDGEMENTS
Jonathan (jrockway) Rockway
+Dave (autarch) Rolsky
+
Piotr (dexter) Roszatycki
Sam (mugwump) Vilain
projects / gitmo/Moose.git / blobdiff