mro(3perl)

📦
version 5.44.0 · 14 versions
, in arch rolling

💖 mro — Method Resolution Order (from the mro(3perl) manual, Perl Programmers Reference Guide) 💖

okay bestie, sit down, we're talking about method resolution order and honestly? it's giving ✨backstage passes to the class hierarchy✨. like who gets called first when your object has seventeen grandmas. this is the mro(3perl) page and it's about to eat, no cap 🍓

🌸 NAME 🌸

mro — Method Resolution Order. that's the whole name. short, iconic, does what it says on the tin 💅

🎀 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

look at her. three lines. main character energy fr fr 👑

🦋 DESCRIPTION 🦋

The mro namespace is your little toolbox for method resolution order and method caching in general. like the backstage crew of Perl's inheritance drama, keeping everything running smooth 🧚

⚠️ heads up babes: these interfaces are only available in Perl 5.9.5 and higher. if you're on something older, go peek at MRO::Compat on CPAN — it's a mostly forwards compatible implementation for the vintage Perls 🫶

🌈 OVERVIEW 🌈

So you wanna change the MRO of a given class? two ways, pick your fighter:

  • use use mro like in the synopsis above, or
  • call the mro::set_mro function (it's down below, don't worry)

and a very important note: the special methods next::method, next::can, and maybe::next::method will not exist until this mro module has been loaded via use or require. like, they're not showing up to the function party until you RSVP. periodt 💀

👑 The C3 MRO 👑

So besides Perl's traditional default MRO (that's depth first search, called "DFS" around these parts), Perl now also offers the C3 MRO. and ngl the C3 support in Perl is based on the work done in Stevan Little's module Class::C3, and most of the C3-related documentation right here is ripped directly from there. we're crediting our sources, we're respectful, we contain multitudes 🌸

✨ What is C3? ✨

C3 is the name of an algorithm, and its whole goal in life is to provide a sane method resolution order under multiple inheritance. it was first introduced in the language Dylan (links are in the SEE ALSO section, bestie, I got you), and then later adopted as the preferred MRO (Method Resolution Order) for the new-style classes in Python 2.3. and most recently? it got adopted as the "canonical" MRO for Raku classes. glow up after glow up honestly 🔥

🦄 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. the algorithm said "respect your elders, but also the elders are the parents, so actually respect the children first" and it's right.

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. The C3 MRO algorithm however, produces the following order: (D, B, C, A), which does not have this issue. slay 💅

This example is fairly trivial; for more complex cases and a deeper explanation, see the links in the SEE ALSO section. we love a footnote moment 🎀

🧚 Functions 🧚

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

Returns an arrayref which is the linearized MRO of the given class. Uses whichever MRO is currently in effect for that class by default, or the given MRO (either "c3" or "dfs" if specified as $type).

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. it's the queue. the lineup. the VIP list in order 🎟️

If the requested class doesn't yet exist, this function will still succeed, and return [ $classname ] — no drama, no error, just vibes 🦋

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. it's the background character that somehow shows up in every scene, but it's not on the call sheet, iykyk 🙈

💜 mro::set_mro ($classname, $type)

Sets the MRO of the given class to the $type argument (either "c3" or "dfs"). one function, one job, ate 💅

💜 mro::get_mro($classname)

Returns the MRO of the given class (either "c3" or "dfs"). the little sister of the function above. so cute 🎀

💜 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. it's the group chat of everyone who claims you as their ancestor, even the cousins twice removed 😭

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. special little diva behavior, we respect it 👑

💜 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. yes queen, you are everybody's ancestor 🔥

💜 mro::invalidate_all_method_caches()

Increments "PL_sub_generation", which invalidates method caching in all packages. nuke the whole cache. clean slate. it's giving spring cleaning ✨

💜 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 here. bestie if you break it, tell the maintainers, don't just suffer in silence 🫶

💜 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, 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. like, your mom redecorating her house does not change your house. your house is your house 💅

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. character development that led right back to where you started, iconic honestly 💀

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 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. gone girl behavior 😭

💜 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. she has her ONE method and she sticks to it 💅

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 identity crisis allowed, you are the method you are 🦋

It can be called on an object or a class, of course. both work, we're inclusive ✨

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). drama! an exception! 💀

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 family tree that doesn't match the seating chart at the wedding 😭

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. she's looking for foo and all she finds is __ANON__, a mystery person with no name. tragic 🙈

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. fixed it for you bestie 🫶✨

💜 next::can

This is similar to "next::method", but just returns either a code reference or "undef" to indicate that no further methods of this name exist. the "are they even there?" text before the "hey what's up" text 💅

💜 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"). sometimes the only one who can handle the situation is the one who checks first 🎀

🌈 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

and that's the whole page, bestie!! you're officially an MRO girlie now, go forth and linearize responsibly 💖✨🎀🦋🌸

this was perl v5.44.0, dated 2026-10-17, from mro(3perl). mwah, thanks for reading, ily, bye 👑💅
📦 where this page comes from