Refactor: Extract Capabilities object #42
Merged
+303
−13
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.
I extracted a Capabilities object, which allows setting the capabilities from the server incrementally and encapsulates the actual calculation of the final capabilities hash.
Motivation and Context
The current
determine_capabilities
approach would need to become a bit more complex to support all the sub-capabilities without interfering with the already supported auto-determination. This would need a bit of custom bookkeeping which if kept in the server would cause quite a bit of cognitive noise. So I extracted it to its own object with an idempotent "support_..." API.This is originally thought as a refactor to prepare for easy implementation of the
Server#support_notifications
method I proposed in #33 - but even if that API should not be adopted after all, I still think it's nice to hide all that capability determination logic in its own object.How Has This Been Tested?
I did not test this manually, but the existing unit tests still pass.
Breaking Changes
No
Types of changes
Checklist
Additional context
None