-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Add a ModuleManagerInterface for determining if a module is enabled #12677
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
Conversation
This is the only method of mentioned class. What is the purpose of proposed interface? |
Purpose is to add an easy ability to determine if a module is enabled to the API. Currently neither the ModuleManager nor the ModuleListInterface are @api annotated |
Interface is only useful when implementation may be potentially switched. Why not mark class method with |
I can do that. I defaulted to an interface b/c I figured it'd be what'd be desired - after all, just b/c I can't think of an alternative implementation doesn't mean one can't exist! Should I PR the addition on the model itself? Doing so would add a couple non-api deprecated methods to the API though |
I was thinking about marking only one method as Let me check in Slack whether there was some reasoning behind not marking this class as |
Raised a question in Slack
|
@orlangur I'm guessing you never got any feedback in Slack? |
@navarr yeah, but now we have a better process. |
@antonkril @buskamuza please take a look on this interface suggestion. Of course it should be done against |
Explicit But yes, such interface with @api annotation makes sense. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
I'm closing this PR to make a new one against 2.3 |
This is a useful addition for feature detection and enablement for third party modules (such as "activate this functionality if such and such GiftCard extension exists"
Contribution checklist