life on the frontier with mro magic
MRO::Magic is a system for writing your own method dispatcher in Perl. I have
written about MRO::Magic before,
but it’s rushing toward being useful as 5.10.1 rushes toward release.
Right now, I have two weird issues. Neither is a real blocker, but both concern me because they really highlight the hairiness of doing this sort of thing.
The first is that in one case, the following line emits an “Uninitialized value in subroutine entry” warning:
In all cases in the test,
$class is the string “Class” and in all but one
case, there is no warning. What? I don’t know if this matters, but it’s
confusing, and makes me feel like my own code is voodoo, which is not a feeling
The other case is more troublesome, as it is likely to drastically affect performance.
Because we’re altering the way that method resolution works, we need to manage
our own method caching, which we can do with the “mro” module. I tried to use
mro::method_changed_in on the classes being magicked, but it failed. It
looked like I’d need to alter superclasses, so I just called the method on
UNIVERSAL and things worked. Of course, this means that any time you called
a method on an MRO::Magic class, you’d clear you entire method cache. Oof!
Today I tried injecting a new, empty package into the
@ISA of magicked
classes and marking it as having changed. This got me neither the
pre-UNIVERSAL-clearing behavior (of failing tests) nor the UNIVERSAL-clearing
behavior (working). Instead, I got deep recursion.
If anyone is feeling brave and wants to have a look at MRO::Magic on 5.10.1 RC1, I would really appreciate it!