-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Enable creating composite subsystem implementation in modules #18888
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
|
@daxian-dbw please address the codefactor isses |
|
This PR has Quantification details
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a
What can I do to optimize my changes
How to interpret the change counts in git diff output
Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email) |
|
@SteveL-MSFT I fixed those CodeFactor issues that can be addressed. The remaining 2 are by design. |
|
🎉 Handy links: |
PR Summary
Fix #18853
Enable creating composite subsystem implementation in modules.
It turns out the
Kindmember inISubsystemis not needed. Whether an implementation derives from the target subsystem interface should be the only criteria to check if this implementation can be registered to the target subsystem.Refactored the subsystem code to remove the
Kindmember from the base interfaceISubsystem, so as to allow one class to implement multiple subsystem interfaces.This is not a breaking change because the
Kindmember was made internal to prevent users from directly implement it. Now one can directly implementsISubsystem, but that implementation won't be able to be registered to PowerShell.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.