stevan
commented
10 years ago I am not sure it makes any sense to apply a trait to a required method for a couple of reasons
1) A number of traits will interact with the body, so the lack of a body would require that those traits handle this case and that seems like an extra burden for not much reward.
2) Since traits are not inherited (by design) then really this basically is just wasting resources to do something that will do nothing.
You could suggest that traits should just no-op (not call the trait function) on required methods and just mark the trait as having been applied, but this too has the problem of completely breaking any trait which might want to use side effects, again creating a special case.
Additionally inflating required methods to be full mop::method objects would be wasteful of memory.
As for the bug in unapply_all_roles please make that a separate issue.
I'm not sure why required methods are not regular mop::method instances, just without a body?
I wrote a simple Pod::Coverage class for mop, but I just noticed it does not support required methods because they are not returned by methods(). I can always get the list of required method names, but they have no associated meta so I can't tell if e.g. they were declared locally.
Making required methods first class citizens would also allow attaching traits to them, so you could e.g. declare that an abstract class must implement stringification with
method as_string is overload("");, and it would solve the bug (?) where required methods disappear from the required method map inunapply_all_roles.If this is a tuit availability problem, I think I got familiar enough with the non-XS parts to have a first go at it, but I'd like to make sure this is considered a bug.