|laziness, impatience, and hubris|
Re: A couple questions on Moose::MOP::Classby stvn (Monsignor)
|on May 03, 2011 at 02:00 UTC||Need Help??|
How can you have a wrapper with no modifiers?
That is referring to the base overhead of Class::MOP::Method::Wrapped, which is the object which must wrap the CODE ref in order to support the method modifiers. So that performance hit that we talk about there is the base cost for using modifiers, any actual modifiers you add onto it costs additional. Think of it like a cover charge :)
Looking at the docs for Sub::Name, I see it gives a name to a sub or a specific instance of a closure for purposes of Carp etc. telling me the correct location. Naming a function does nothing to install it into the Package, which is what is used for method dispatch. When doing dispatch, the name in the Package (symbol table) is what is used as "the" name to look up, so what does giving it a different internal name have to do with anything?
Moose and Class::MOP make a distinction between methods defined in your class, and functions imported from other modules. This is why if you import function 'foo' from module 'Foo::Bar' in your role, and then compose your role into a class, the class will not have a 'foo' method. Similarly if you query the methods of a class via the MOP, you will find that there are no imported functions in the list, even though they are still in your symbol table (assuming you are not using namespace::clean that is).
So since Perl has no real way to tell the difference between a method and a function, Moose had to devise a test for method purity. The test that was settled on was to dive deep into the B level of things and look at the names in the actual stash. If a CV structure is linked to the proper package stash then we know that it was defined in that package and we can therefore assume it is a method. If it has a different package stash name, then we assume it is imported and therefore is not a method. This works great except that Moose generates a LOT of methods and those would not, on their own, have the proper package stash name. So what Sub::Name provides is exactly that, it allows you to take a CV and assign the package stash name as well as the CV stash name.
Welcome to the twisty maze of ugliness that is making Perl 5 bend to your whim (and do so with a production-quality level of stability too).