use mro; # enables next::method and friends globally use mro 'dfs'; # enable DFS MRO for this class (Perl default) use mro 'c3'; # enable C3 MRO for this class
These interfaces are only available in Perl 5.9.5 and higher. See MRO::Compat on CPAN for a mostly forwards compatible implementation for older Perls.
The special methods "next::method", "next::can", and "maybe::next::method" are not available until this "mro" module has been loaded via "use" or "require".
<A>
/ \
<B> <C>
\ /
<D>
The standard Perl 5 MRO would be (D, B, A, C). The result being that A appears before C, even though C is the subclass of A. The C3 MRO algorithm however, produces the following order: (D, B, C, A), which does not have this issue.
This example is fairly trivial; for more complex cases and a deeper explanation, see the links in the ``SEE ALSO'' section.
The linearized MRO of a class is an ordered array of all of the classes one would search when resolving a method on that class, starting with the class itself.
If the requested class doesn't yet exist, this function will still succeed, and return "[ $classname ]"
Note that "UNIVERSAL" (and any members of "UNIVERSAL"'s MRO) are not part of the MRO of a class, even though all classes implicitly inherit methods from "UNIVERSAL" and its parents.
Currently, this list only grows, it never shrinks. This was a performance consideration (properly tracking and deleting isarev entries when someone removes an entry from an @ISA is costly, and it doesn't happen often anyways). The fact that a class which no longer truly ``isa'' this class at runtime remains on the list should be considered a quirky implementation detail which is subject to future change. It shouldn't be an issue as long as you're looking at this list for the same reasons the core code does: as a performance optimization over having to search every class in existence.
As with "mro::get_mro" above, "UNIVERSAL" is special. "UNIVERSAL" (and parents') isarev lists do not include every class in existence, even though all classes are effectively descendants for method inheritance purposes.
Any class for which this function returns true is ``universal'' in the sense that all classes potentially inherit methods from it.
For similar reasons to "isarev" above, this flag is permanent. Once it is set, it does not go away, even if the class in question really isn't universal anymore.
This is intended for authors of modules which do lots of class introspection, as it allows them to very quickly check if anything important about the local properties of a given class have changed since the last time they looked. It does not increment on method/@ISA changes in superclasses.
It's still up to you to seek out the actual changes, and there might not actually be any. Perhaps all of the changes since you last checked cancelled each other out and left the package in the state it was in before.
This integer normally starts off at a value of 1 when a package stash is instantiated. Calling it on packages whose stashes do not exist at all will return 0. If a package stash is completely deleted (not a normal occurence, but it can happen if someone does something like "undef %PkgName::"), the number will be reset to either 0 or 1, depending on how completely package was wiped out.
One generally uses it like so:
sub some_method {
my $self = shift;
my $superclass_answer = $self->next::method(@_);
return $superclass_answer + 1;
}
Note that you don't (re-)specify the method name. It forces you to always use the same method name as the method you started in.
It can be called on an object or a class, of course.
The way it resolves which actual method to call is:
Failure to find a next method will result in an exception being thrown (see below for alternatives).
This is substantially different than the behavior of "SUPER" under complex multiple inheritance. (This becomes obvious when one realizes that the common superclasses in the C3 linearizations of a given class and one of its parents will not always be ordered the same for both.)
Caveat: Calling "next::method" from methods defined outside the class:
There is an edge case when using "next::method" from within a subroutine which was created in a different module than the one it is called from. It sounds complicated, but it really isn't. Here is an example which will not work correctly:
*Foo::foo = sub { (shift)->next::method(@_) };
The problem exists because the anonymous subroutine being assigned to the *Foo::foo glob will show up in the call stack as being called "__ANON__" and not "foo" as you might expect. Since "next::method" uses "caller" to find the name of the method it was called in, it will fail in this case.
But fear not, there's a simple solution. The module "Sub::Name" will reach into the perl internals and assign a name to an anonymous subroutine for you. Simply do this:
use Sub::Name 'subname';
*Foo::foo = subname 'Foo::foo' => sub { (shift)->next::method(@_) };
$self->next::method(@_) if $self->next_can;
But there are some cases where only this solution works (like "goto &maybe::next::method");
Based on Stevan Little's Class::C3