| Class::MOP::Class - Class Meta Object |
Class::MOP::Class - Class Meta Object
# assuming that class Foo # has been defined, you can
# use this for introspection ...
# add a method to Foo ...
Foo->meta->add_method('bar' => sub { ... })
# get a list of all the classes searched # the method dispatcher in the correct order Foo->meta->class_precedence_list()
# remove a method from Foo
Foo->meta->remove_method('bar');
# or use this to actually create classes ...
Class::MOP::Class->create('Bar' => (
version => '0.01',
superclasses => [ 'Foo' ],
attributes => [
Class::MOP:::Attribute->new('$bar'),
Class::MOP:::Attribute->new('$baz'),
],
methods => {
calculate_bar => sub { ... },
construct_baz => sub { ... }
}
));
This is the largest and currently most complex part of the Perl 5 meta-object protocol. It controls the introspection and manipulation of Perl 5 classes (and it can create them too). The best way to understand what this module can do, is to read the documentation for each of it's methods.
As with Class::MOP::Attribute, Class::MOP will actually bootstrap this module by installing a number of attribute meta-objects into it's metaclass. This will allow this class to reap all the benifits of the MOP when subclassing it.
These methods will handle creating Class::MOP::Class objects, which can be used to both create new classes, and analyze pre-existing classes.
This module will internally store references to all the instances you create with these methods, so that they do not need to be created any more than nessecary. Basically, they are singletons.
$package_name into existence and adding any of the $version,
$authority, @superclasses, %methods and %attributes to
it.
create but
it does not need a $package_name. Instead it will create a suitably
unique package name for you to stash things into.
On very important distinction is that anon classes are destroyed once the metaclass they are attached to goes out of scope. In the DESTROY method, the created package will be removed from the symbol table.
It is also worth noting that any instances created with an anon-class
will keep a special reference to the anon-meta which will prevent the
anon-class from going out of scope until all instances of it have also
been destroyed. This however only works for HASH based instance types,
as we use a special reserved slot (__MOP__) to store this.
$package_name.
construct_instance once all the bootstrapping is done. This
method is used internally by initialize and should never be called
from outside of that method really.
construct_class_instance method. This will check that the
metaclass you are creating is compatible with the metaclasses of all
your ancestors. For more inforamtion about metaclass compatibility
see the About Metaclass compatibility section in the Class::MOP manpage.
Class::MOP::get_package_cache_flag
function. This is very rarely needed from outside of Class::MOP::Class
but in some cases you might want to use it, so it is here.
These methods are entirely optional, it is up to you whether you want to use them or not.
new this method like so:
sub MyClass::new {
my ($class, %param) = @_;
$class->meta->new_object(%params);
}
bless-ing into your package of choice. It works in conjunction
with the Attribute protocol to collect all applicable attributes.
This will construct and instance using a HASH ref as storage
(currently only HASH references are supported). This will collect all
the applicable attributes and layout out the fields in the HASH ref,
it will then initialize them using either use the corresponding key
in %params or any default value or initializer found in the
attribute meta-object.
clone_instance, which performs a shallow copy of the object,
see that methods documentation for more details. Ideally your
class would call a clone this method like so:
sub MyClass::clone {
my ($self, %param) = @_;
$self->meta->clone_object($self, %params);
}
construct_instance (which means if
you override construct_instance, you need to override this one too),
and clones the instance shallowly.
The cloned structure returned is (like with construct_instance) an
unblessed HASH reference, it is your responsibility to then bless
this cloned structure into the right class (which clone_object will
do for you).
As of 0.11, this method will clone the $instance structure shallowly,
as opposed to the deep cloning implemented in prior versions. After much
thought, research and discussion, I have decided that anything but basic
shallow cloning is outside the scope of the meta-object protocol. I
think Yuval ``nothingmuch'' Kogman put it best when he said that cloning
is too context-specific to be part of the MOP.
$instance to the class of the invoking
Class::MOP::Class. You may only rebless the instance to a subclass of
itself. You may pass in optional %params which are like constructor
params and will override anything already defined in the instance.
These are a few predicate methods for asking information about the class.
Class::MOP::Class created anon class.
@ISA for you.
class_precedence_list but with all
duplicates removed.
$method_name and CODE reference to that
$method and install it into the class's package.
NOTE:
This does absolutely nothing special to $method
other than use Sub::Name to make sure it is tagged with the
correct name, and therefore show up correctly in stack traces and
such.
$method_name and CODE reference to that
$method and alias the method into the class's package.
NOTE:
Unlike add_method, this will not try to name the
$method using Sub::Name, it only aliases the method in
the class's package.
$method_name. It will not however, attempt to check
if the class inherits the method (use UNIVERSAL::can for that).
This will correctly handle functions defined outside of the package
that use a fully qualified name (sub Package::name { ... }).
This will correctly handle functions renamed with Sub::Name and
installed using the symbol tables. However, if you are naming the
subroutine outside of the package scope, you must use the fully
qualified name, including the package name, for has_method to
correctly identify it.
This will attempt to correctly ignore functions imported from other
packages using Exporter. It breaks down if the function imported
is an __ANON__ sub (such as with use constant), which very well
may be a valid method being applied to the class.
In short, this method cannot always be trusted to determine if the
$method_name is actually a method. However, it will DWIM about
90% of the time, so it's a small trade off I think.
$method_name, or return undef if that method does not exist.
The Class::MOP::Method is codifiable, so you can use it like a normal CODE reference, see the Class::MOP::Method manpage for more information.
$method_name,
or return undef if that method does not exist.
Unlike get_method this will also look in the superclasses.
$method_name from the class.
It will return the CODE reference that it has removed, and will
attempt to use Sub::Name to clear the methods associated name.
compute_all_applicable_methods method.
$method_name. Similar to
compute_all_applicable_methods it returns a list of HASH references
with the following information; method name (which will always be the
same as $method_name), the name of the class in which the method
lives and a CODE reference for the actual method.
The list of methods produced is a distinct list, meaning there are no duplicates in it. This is especially useful for things like object initialization and destruction where you only want the method called once, and in the correct order.
$method_name in
the superclasses, this is basically equivalent to calling
SUPER::$method_name, but it can be dispatched at runtime.
Method modifiers are a concept borrowed from CLOS, in which a method can be wrapped with before, after and around method modifiers that will be called everytime the method is called.
Method modifiers work by wrapping the original method and then replacing it in the classes symbol table. The wrappers will handle calling all the modifiers in the appropariate orders and preserving the calling context for the original method.
Each method modifier serves a particular purpose, which may not be obvious to users of other method wrapping modules. To start with, the return values of before and after modifiers are ignored. This is because thier purpose is not to filter the input and output of the primary method (this is done with an around modifier). This may seem like an odd restriction to some, but doing this allows for simple code to be added at the begining or end of a method call without jeapordizing the normal functioning of the primary method or placing any extra responsibility on the code of the modifier. Of course if you have more complex needs, then use the around modifier, which uses a variation of continutation passing style to allow for a high degree of flexibility.
Before and around modifiers are called in last-defined-first-called order, while after modifiers are called in first-defined-first-called order. So the call tree might looks something like this:
before 2
before 1
around 2
around 1
primary
after 1
after 2
To see examples of using method modifiers, see the following examples included in the distribution; InstanceCountingClass, Perl6Attribute, AttributesWithHistory and C3MethodDispatchOrder. There is also a classic CLOS usage example in the test 017_add_method_modifier.t.
Of course there is a performance cost associated with method modifiers, but we have made every effort to make that cost be directly proportional to the amount of modifier features you utilize.
The wrapping method does it's best to only do as much work as it absolutely needs to. In order to do this we have moved some of the performance costs to set-up time, where they are easier to amortize.
All this said, my benchmarks have indicated the following:
simple wrapper with no modifiers 100% slower simple wrapper with simple before modifier 400% slower simple wrapper with simple after modifier 450% slower simple wrapper with simple around modifier 500-550% slower simple wrapper with all 3 modifiers 1100% slower
These numbers may seem daunting, but you must remember, every feature
comes with some cost. To put things in perspective, just doing a simple
AUTOLOAD which does nothing but extract the name of the method called
and return it costs about 400% over a normal method call.
$method_name and the supplied $code
will be passed the @_ arguments, and called before the original
method is called. As specified above, the return value of the before
method modifiers is ignored, and it's ability to modify @_ is
fairly limited. If you need to do either of these things, use an
around method modifier.
$method_name so that the original
method will be called, it's return values stashed, and then the
supplied $code will be passed the @_ arguments, and called.
As specified above, the return value of the after method
modifiers is ignored, and it cannot modify the return values of
the original method. If you need to do either of these things, use an
around method modifier.
$method_name so that $code
will be called and passed the original method as an extra argument
at the begining of the @_ argument list. This is a variation of
continuation passing style, where the function prepended to @_
can be considered a continuation. It is up to $code if it calls
the original method or not, there is no restriction on what the
$code can or cannot do.
It should be noted that since there is no one consistent way to define the attributes of a class in Perl 5. These methods can only work with the information given, and can not easily discover information on their own. See the Class::MOP::Attribute manpage for more details.
$attribute_meta_object (or creates one from the
$attribute_name and %attribute_spec) in the Class::MOP::Class
instance associated with the given class. Unlike methods, attributes
within the MOP are stored as meta-information only. They will be used
later to construct instances from (see construct_instance above).
More details about the attribute meta-objects can be found in the
the Class::MOP::Attribute manpage or the The Attribute protocol in the Class::MOP manpage
section.
It should be noted that any accessor, reader/writer or predicate
methods which the $attribute_meta_object has will be installed
into the class at this time.
NOTE
If an attribute already exists for $attribute_name, the old one
will be removed (as well as removing all it's accessors), and then
the new one added.
$attribute_name and returns a boolean.
$attribute_name,
if none is found, it will return undef.
$attribute_name, then return the removed attribute meta-object.
NOTE: Removing an attribute will only affect future instances of the class, it will not make any attempt to remove the attribute from any existing instances of the class.
It should be noted that any accessor, reader/writer or predicate
methods which the attribute meta-object stored at $attribute_name
has will be removed from the class at this time. This will make
these attributes somewhat inaccessable in previously created
instances. But if you are crazy enough to do this at runtime, then
you are crazy enough to deal with something like this :).
compute_all_applicable_attributes method.
compute_all_applicable_methods because all
that same information is discoverable through the attribute
meta-object itself.
$attr_name, then return it.
It will return undef if nothing is found.
Stevan Little <stevan@iinteractive.com>
Copyright 2006-2008 by Infinity Interactive, Inc.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
| Class::MOP::Class - Class Meta Object |