mro(3pm)

💅 mro — Method Resolution Order (yes bestie, the method-finding lore) 🎀

Okay so this is mro(3pm) from the Perl Programmers Reference Guide, and honestly? It's giving "let me explain how Perl decides which method you actually meant." Buckle up. ✨

🌸 NAME 🌸

mro — Method Resolution Order. That's it. That's the whole name. Iconic behavior, no notes.

✨ SYNOPSIS ✨

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

💖 DESCRIPTION 💖

So the mro namespace hands you a whole little toolkit for dealing with method resolution order and method caching in general. Very "behind the scenes but make it accessible" of it.

Heads up bestie: these interfaces are only available in Perl 5.9.5 and higher. If you're on an older Perl, go look at MRO::Compat on CPAN for a mostly forwards compatible implementation. 🫶

🦋 OVERVIEW 🦋

You can change the MRO of a given class either by using use mro (like the synopsis showed you) or by calling the mro::set_mro function lower down. Two roads, same destination, slay.

Now the important part: those special methods next::method, next::can, and maybe::next::method are not available until this mro module has actually been loaded via use or require. Like, they're not just vibing there waiting for you. Load the module first, periodt.

---

🔥 The C3 MRO 🔥

So besides the traditional Perl default MRO — which is depth first search, and yeah we're calling it "DFS" here — Perl now also offers the C3 MRO. Perl's C3 support is based on the work done in Stevan Little's module Class::C3, and most of the C3-related documentation you're about to read is ripped directly from there. Credit where credit is due. 👑

🧚 What is C3?

C3 is the name of an algorithm that aims to provide a sane method resolution order under multiple inheritance. It was first introduced in the language Dylan (links are down in SEE ALSO, iykyk), and then later adopted as the preferred MRO (Method Resolution Order) for the new-style classes in Python 2.3. And most recently? It's been adopted as the "canonical" MRO for Raku classes. It's been around, it's well-traveled, it's that girl. 💅

⭐ How does C3 work

C3 works by always preserving local precedence ordering. Which essentially means: no class will ever appear before any of its subclasses. Rude behavior, prevented. 🎀

Take, for instance, the classic diamond inheritance pattern:

     <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. Lowkey messy. 😭

The C3 MRO algorithm however produces the following order: (D, B, C, A), which does not have this issue. Glow up. ✨

This example is fairly trivial though — for more complex cases and a deeper explanation, go check the links in the SEE ALSO section. No cap.

---

🫶 Functions 🫶

mro::get_linear_isa($classname[, $type])

Returns an arrayref which is the linearized MRO of the given class. By default it uses whichever MRO is currently in effect for that class, or the given MRO (c3 or dfs) if you specify it as $type.

The linearized MRO of a class is an ordered array of all the classes you'd search when resolving a method on that class, starting with the class itself. First one in the list is the class you asked about, bestie. 💖

If the requested class doesn't exist yet, this function will still succeed, and return [ $classname ]. It's not gonna throw hands over a missing package.

Note: 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. Yes this is a little weird. It's fine. It's documented. 🌈

mro::set_mro($classname, $type)

Sets the MRO of the given class to the $type argument — either c3 or dfs. That's the whole function. Choose your fighter. 🥊

mro::get_mro($classname)

Returns the MRO of the given class — either c3 or dfs. The vibes check of a class. 🦋

mro::get_isarev($classname)

Gets the mro_isarev for this class, returned as an arrayref of class names. These are every class that isa the given class name — even if the isa relationship is indirect. This is used internally by the MRO code to keep track of method/MRO cache invalidations.

As with mro::get_linear_isa 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. It gets a pass. Main character energy. 👑

mro::is_universal($classname)

Returns a boolean status indicating whether or not the given classname is either UNIVERSAL itself, or one of UNIVERSAL's parents by @ISA inheritance.

Any class for which this function returns true is "universal" in the sense that all classes potentially inherit methods from it. Big "everyone's ancestor" vibe. 🌸

mro::invalidate_all_method_caches()

Increments PL_sub_generation, which invalidates method caching in all packages. Everything, everywhere, all at once. 💀

mro::method_changed_in($classname)

Invalidates the method cache of any classes dependent on the given class. This is not normally necessary.

The only known case where pure perl code can confuse the method cache is when you manually install a new constant subroutine by using a readonly scalar value, like the internals of constant do. If you find another case, please report it so we can either fix it or document the exception right here. 🙈

mro::get_pkg_gen($classname)

Returns an integer which is incremented every time a real local method in the package $classname changes, or the local @ISA of $classname is modified.

This is intended for authors of modules which do lots of class introspection, because it lets them very quickly check if anything important about the local properties of a given class has changed since the last time they looked. Very "did anything happen while I was gone" of it.

It does not increment on method/@ISA changes in superclasses. Only the locals, bestie.

It's still up to you to seek out the actual changes, and there might not actually be any. Maybe all of the changes since you last checked cancelled each other out and left the package in the exact state it was in before. Chaotic but valid. 😭

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. And if a package stash is completely deleted (not a normal occurrence, 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 the package was wiped out. 💀

next::method

This is somewhat like SUPER, but it uses the C3 method resolution order to get better consistency in multiple inheritance situations. Note that while inheritance in general follows whichever MRO is in effect for the given class, next::method only uses the C3 MRO. Picky? A little. Correct? Yes. ✨

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. No renaming your way out of this one.

It can be called on an object or a class, of course. Either is fine, we don't gatekeep. 🫶

The way it resolves which actual method to call is:

1. First, it determines the linearized C3 MRO of the object or class it is being called on.
2. Then, it determines the class and method name of the context it was invoked from.
3. Finally, it searches down the C3 MRO list until it reaches the contextually enclosing class, then searches further down the MRO list for the next method with the same name as the contextually enclosing method.

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.) It's giving "the math is mathing but it's not the math you expected." 🔥

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: perl *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(@_) };

and things will Just Work. 🎀 Slay.

next::can

This is similar to next::method, but it just returns either a code reference or undef to indicate that no further methods of this name exist. No exceptions, just a little boolean-flavored answer. 🦋

maybe::next::method

In simple cases, it is equivalent to:

$self->next::method(@_) if $self->next::can;

But there are some cases where only this solution works (like goto &maybe::next::method). Special little guy. 💜

---

🧚 SEE ALSO 🧚

📄 The original Dylan paper

<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.19.3910&rep=rep1&type=pdf>

🐍 Python 2.3 MRO

<https://www.python.org/download/releases/2.3/mro/>

💎 Class::C3

Class::C3

---

👑 AUTHOR 👑

Brandon L. Black, <blblack@gmail.com>

Based on Stevan Little's Class::C3. Respect where it's due. 🫶

---

And that's the whole page, bestie — brought to you by perl v5.42.3, dated 2026-11-03, page mro(3pm). Go resolve some methods. 💅✨