From 1208af078edde335decfa1cc1eaf14fe92e13268 Mon Sep 17 00:00:00 2001 From: Tomas Doran Date: Tue, 9 Feb 2010 22:49:29 +0000 Subject: [PATCH] Remove my hideous hack after autarch++ fixed Moose in cf600c8 --- .../Role/Meta/Role/Application.pm | 20 +------------------ 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/lib/MooseX/MethodAttributes/Role/Meta/Role/Application.pm b/lib/MooseX/MethodAttributes/Role/Meta/Role/Application.pm index cb0907f..740dbd0 100644 --- a/lib/MooseX/MethodAttributes/Role/Meta/Role/Application.pm +++ b/lib/MooseX/MethodAttributes/Role/Meta/Role/Application.pm @@ -48,25 +48,7 @@ sub _apply_metaclasses { # into lies by the metatrait role application process, so we explicitly # re-fetch it here. - # Alternatively, for epic shits and giggles, the meta trait application - # process (onto $thing) may have applied roles to our metaclass, but (if - # $thing is an anon class, not correctly replaced it in the metaclass cache. - # This results in the DESTROY method in Class::MOP::Class r(eap|ape)ing the - # package, which is unfortunate, as it removes all your methods and superclasses. - # Therefore, we avoid that by ramming the metaclass we've just been handed into - # the cache without weakening it. - - # I'm fairly sure the 2nd part of that is a Moose bug, and should go away.. - # Unfortunately, the implication of that is that whenever you apply roles to a class, - # the metaclass instance can change, and so needs to be re-retrieved or handed back - # to the caller :/ - if ($thing->can('is_anon_class') and $thing->is_anon_class) { - Class::MOP::store_metaclass_by_name($thing->name, $thing); - } - else { - return find_meta($thing->name); - } - return $thing; + return find_meta($thing->name); } 1;