Todd, > Not quite... We're not changing the default metaclass for everything, but > rather applying a metarole to the metaclass of the consuming class. (I think > that's how it goes -- I'm still not sure of the correct terminology.)
Yes, true, but my thinking goes (and I freely admit I could be wrong on the details) that, by applying a metarole to the metaclass, that generates an anonymous class which composes the role. So it is, in effect, a new metaclass, not technically for everything, but for everything from that point forward (till end of file or end of scope). > (If you're > concerned about prompting during cloning and/or reblessing, there'll be a > little more work to do.) Perhaps, although at that point there would be a value from the original instantiation, so as long as I only prompt when there's no value, I should be good. > Don't know if it's a good approach by Moose Cabal > standards, but it's direct. True. :-) LIS, I'm just wondering what people think about the two approaches: creating an attribute trait vs applying a metarole to the metaclass. Is one better than the other in certain respects? Is one academically/philosophically better (an interesting point, although mostly moot)? What about practical aspects? Does one work in scenario X where the other doesn't? That sort of thing. Back to ealleniii's solution, I managed to track down the add_attribute() method of the metaclass (it's in Class::MOP::Mixin::HasAttributes; not sure why I couldn't find that on CPAN) and I see it is indeed smart enough to remove the old attribute of the same name before adding the new one. I'm still a little fuzzy on whether the memory would get freed, but I'm assuming so. So I'm going to play around with this one a bit more. -- Buddy
