On Thu, Oct 14, 2010 at 6:24 PM, Dave Rolsky <[email protected]> wrote: > On Thu, 14 Oct 2010, Lars Balker Rasmussen wrote: >> Why would the role application be relying on the presence or not of a >> method modifier in B? "Compile time" application with "with 'R'" in B >> works as expected. Removing the modifier in C also makes the runtime >> application take, so it appears that something is cached in C? > > Yes, there is some caching that I suspect is the problem. Applying the > method modifier caches all the subs to be called, so when you apply the > modifier to C, it caches this. When applying the modifier to B _after_ this > (regardless of how it's done), Moose does not recalculate the cache for > methods in C. > > I suspect this is fixable.
Sounds good. In the meantime, is there a way to force a recalculation for this cache? I already have complete lists of the involved classes and roles at application time, so it wouldn't be too horrible to run through them. > Note that in the common case of immutable classes, we would not expect this > to work (that's what immutable means ;) so I'm not sure how important this > is. We're (eventually) forcing immutable for all our own classes after runtime application of the roles, so I was hoping to be able to modify the classes at will before then (make_immutable is tested for globally in the test suite along with a couple of other incompatible uses, so it shouldn't cause problems). > Is this something that actually comes up in real code? We're depending on this feature right now, yes. I can work around it for now, but it'll be a pain to maintain/extend. -- Lars Balker Rasmussen Consult::Perl
