refactor: add support for Custom Skip Voters #5002
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
This pull request refactors the constructor of the Skipper class to improve its compatibility with dependency injection and to support custom SkipVoter implementations.
Changes Made:
Changed the constructor to accept an iterable of SkipVoterInterface objects, allowing for more flexibility in injecting multiple skip voters without having to explicitly list them.
Added a type hint for the $skipVoters parameter to ensure that all elements within the iterable are instances of SkipVoterInterface.
Used the Assert::allIsInstanceOf method to validate that all elements in $skipVoters are indeed instances of SkipVoterInterface.
Reasoning:
In version 0.16.0, before the introduction of the new Lazy Container, I implemented a custom SkipVoter for the company I work for. This custom implementation worked seamlessly. However, with the introduction of the Lazy Container and the subsequent change in the constructor signature, the ability to use custom SkipVoter implementations was hindered.
By allowing an iterable of skip voters, we can easily extend or modify the list of skip voters without changing the constructor signature. This change also aligns better with dependency injection principles, making it easier to bind and inject dependencies.
Furthermore, I plan to submit another pull request proposing a new "collector" based skip voter. The idea behind this is to provide a configurable mechanism to skip classes based on specific criteria, such as implementing a certain interface or extending a specific class.
Potential Concerns:
Backward Compatibility: This change might affect parts of the codebase or external projects that rely on the old constructor signature.
Performance: Using an iterable and asserting all elements might introduce a slight performance overhead. The impact should be minimal.
3. Original Design Intent: I'd love to understand the original intention behind the design change. The previous design might have been intentional to restrict the number or type of skip voters. It's essential to ensure that this change aligns with the project's goals.