{ "mode": "perldoc", "parameter": "mro", "section": "", "url": "https://www.chedong.com/phpMan.php/perldoc/mro/json", "generated": "2026-10-04T18:26:19Z", "synopsis": "use mro; # enables next::method and friends globally\nuse mro 'dfs'; # enable DFS MRO for this class (Perl default)\nuse mro 'c3'; # enable C3 MRO for this class", "sections": { "NAME": { "content": "mro - Method Resolution Order\n", "subsections": [] }, "SYNOPSIS": { "content": "use mro; # enables next::method and friends globally\n\nuse mro 'dfs'; # enable DFS MRO for this class (Perl default)\nuse mro 'c3'; # enable C3 MRO for this class\n", "subsections": [] }, "DESCRIPTION": { "content": "The \"mro\" namespace provides several utilities for dealing with method resolution order and\nmethod caching in general.\n\nThese interfaces are only available in Perl 5.9.5 and higher. See MRO::Compat on CPAN for a\nmostly forwards compatible implementation for older Perls.\n", "subsections": [] }, "OVERVIEW": { "content": "It's possible to change the MRO of a given class either by using \"use mro\" as shown in the\nsynopsis, or by using the \"mro::setmro\" function below.\n\nThe special methods \"next::method\", \"next::can\", and \"maybe::next::method\" are not available\nuntil this \"mro\" module has been loaded via \"use\" or \"require\".\n\nThe C3 MRO\nIn addition to the traditional Perl default MRO (depth first search, called \"DFS\" here), Perl\nnow offers the C3 MRO as well. Perl's support for C3 is based on the work done in Stevan\nLittle's module Class::C3, and most of the C3-related documentation here is ripped directly from\nthere.\n\nWhat is C3?\nC3 is the name of an algorithm which aims to provide a sane method resolution order under\nmultiple inheritance. It was first introduced in the language Dylan (see links in the \"SEE ALSO\"\nsection), and then later adopted as the preferred MRO (Method Resolution Order) for the\nnew-style classes in Python 2.3. Most recently it has been adopted as the \"canonical\" MRO for\nRaku classes.\n", "subsections": [ { "name": "How does C3 work", "content": "C3 works by always preserving local precedence ordering. This essentially means that no class\nwill appear before any of its subclasses. Take, for instance, the classic diamond inheritance\npattern:\n\n\n/ \\\n \n\\ /\n\n\nThe standard Perl 5 MRO would be (D, B, A, C). The result being that A appears before C, even\nthough C is the subclass of A. The C3 MRO algorithm however, produces the following order: (D,\nB, C, A), which does not have this issue.\n\nThis example is fairly trivial; for more complex cases and a deeper explanation, see the links\nin the \"SEE ALSO\" section.\n" } ] }, "Functions": { "content": "mro::getlinearisa($classname[, $type])\nReturns an arrayref which is the linearized MRO of the given class. Uses whichever MRO is\ncurrently in effect for that class by default, or the given MRO (either \"c3\" or \"dfs\" if\nspecified as $type).\n\nThe linearized MRO of a class is an ordered array of all of the classes one would search when\nresolving a method on that class, starting with the class itself.\n\nIf the requested class doesn't yet exist, this function will still succeed, and return \"[\n$classname ]\"\n\nNote that \"UNIVERSAL\" (and any members of \"UNIVERSAL\"'s MRO) are not part of the MRO of a class,\neven though all classes implicitly inherit methods from \"UNIVERSAL\" and its parents.\n\nmro::setmro ($classname, $type)\nSets the MRO of the given class to the $type argument (either \"c3\" or \"dfs\").\n\nmro::getmro($classname)\nReturns the MRO of the given class (either \"c3\" or \"dfs\").\n\nmro::getisarev($classname)\nGets the \"mroisarev\" for this class, returned as an arrayref of class names. These are every\nclass that \"isa\" the given class name, even if the isa relationship is indirect. This is used\ninternally by the MRO code to keep track of method/MRO cache invalidations.\n\nAs with \"mro::getlinearisa\" above, \"UNIVERSAL\" is special. \"UNIVERSAL\" (and parents') isarev\nlists do not include every class in existence, even though all classes are effectively\ndescendants for method inheritance purposes.\n\nmro::isuniversal($classname)\nReturns a boolean status indicating whether or not the given classname is either \"UNIVERSAL\"\nitself, or one of \"UNIVERSAL\"'s parents by @ISA inheritance.\n\nAny class for which this function returns true is \"universal\" in the sense that all classes\npotentially inherit methods from it.\n\nmro::invalidateallmethodcaches()\nIncrements \"PLsubgeneration\", which invalidates method caching in all packages.\n\nmro::methodchangedin($classname)\nInvalidates the method cache of any classes dependent on the given class. This is not normally\nnecessary. The only known case where pure perl code can confuse the method cache is when you\nmanually install a new constant subroutine by using a readonly scalar value, like the internals\nof constant do. If you find another case, please report it so we can either fix it or document\nthe exception here.\n\nmro::getpkggen($classname)\nReturns an integer which is incremented every time a real local method in the package $classname\nchanges, or the local @ISA of $classname is modified.\n\nThis is intended for authors of modules which do lots of class introspection, as it allows them\nto very quickly check if anything important about the local properties of a given class have\nchanged since the last time they looked. It does not increment on method/@ISA changes in\nsuperclasses.\n\nIt's still up to you to seek out the actual changes, and there might not actually be any.\nPerhaps all of the changes since you last checked cancelled each other out and left the package\nin the state it was in before.\n\nThis integer normally starts off at a value of 1 when a package stash is instantiated. Calling\nit on packages whose stashes do not exist at all will return 0. If a package stash is completely\ndeleted (not a normal occurrence, but it can happen if someone does something like \"undef\n%PkgName::\"), the number will be reset to either 0 or 1, depending on how completely the package\nwas wiped out.\n\nnext::method\nThis is somewhat like \"SUPER\", but it uses the C3 method resolution order to get better\nconsistency in multiple inheritance situations. Note that while inheritance in general follows\nwhichever MRO is in effect for the given class, \"next::method\" only uses the C3 MRO.\n\nOne generally uses it like so:\n\nsub somemethod {\nmy $self = shift;\nmy $superclassanswer = $self->next::method(@);\nreturn $superclassanswer + 1;\n}\n\nNote that you don't (re-)specify the method name. It forces you to always use the same method\nname as the method you started in.\n\nIt can be called on an object or a class, of course.\n\nThe way it resolves which actual method to call is:\n\n1 First, it determines the linearized C3 MRO of the object or class it is being called on.\n\n2 Then, it determines the class and method name of the context it was invoked from.\n\n3 Finally, it searches down the C3 MRO list until it reaches the contextually enclosing class,\nthen searches further down the MRO list for the next method with the same name as the\ncontextually enclosing method.\n\nFailure to find a next method will result in an exception being thrown (see below for\nalternatives).\n\nThis is substantially different than the behavior of \"SUPER\" under complex multiple inheritance.\n(This becomes obvious when one realizes that the common superclasses in the C3 linearizations of\na given class and one of its parents will not always be ordered the same for both.)\n\nCaveat: Calling \"next::method\" from methods defined outside the class:\n\nThere is an edge case when using \"next::method\" from within a subroutine which was created in a\ndifferent module than the one it is called from. It sounds complicated, but it really isn't.\nHere is an example which will not work correctly:\n\n*Foo::foo = sub { (shift)->next::method(@) };\n\nThe problem exists because the anonymous subroutine being assigned to the *Foo::foo glob will\nshow up in the call stack as being called \"ANON\" and not \"foo\" as you might expect. Since\n\"next::method\" uses \"caller\" to find the name of the method it was called in, it will fail in\nthis case.\n\nBut fear not, there's a simple solution. The module \"Sub::Name\" will reach into the perl\ninternals and assign a name to an anonymous subroutine for you. Simply do this:\n\nuse Sub::Name 'subname';\n*Foo::foo = subname 'Foo::foo' => sub { (shift)->next::method(@) };\n\nand things will Just Work.\n\nnext::can\nThis is similar to \"next::method\", but just returns either a code reference or \"undef\" to\nindicate that no further methods of this name exist.\n\nmaybe::next::method\nIn simple cases, it is equivalent to:\n\n$self->next::method(@) if $self->next::can;\n\nBut there are some cases where only this solution works (like \"goto &maybe::next::method\");\n", "subsections": [] }, "SEE ALSO": { "content": "", "subsections": [ { "name": "The original Dylan paper", "content": "\n" }, { "name": "Python 2.3 MRO", "content": "\n" }, { "name": "Class::C3", "content": "Class::C3\n" } ] }, "AUTHOR": { "content": "Brandon L. Black, \n\nBased on Stevan Little's Class::C3\n", "subsections": [] } }, "summary": "mro - Method Resolution Order", "flags": [], "examples": [], "see_also": [] }