Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different APIs for required and regular methods #157

Open
fgabolde opened this issue Feb 4, 2014 · 1 comment
Open

Different APIs for required and regular methods #157

fgabolde opened this issue Feb 4, 2014 · 1 comment

Comments

@fgabolde
Copy link

fgabolde commented Feb 4, 2014

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 in unapply_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.

@stevan
Copy link
Owner

stevan commented Feb 4, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants