Make MethodCall classes non-generic
#663
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Remove the fluent API interface implementations from `MethodCall` et al., and create new dedicated API types that implement them instead. To start off, these new types simply forward all calls to the `Method- Call` instances that they wrap. This might initially seem pointless, but it means that `MethodCall` et al. are no longer forced to implement lots of duplicate methods and be generic just because the fluent API requires it. We'll be able to trim down `MethodCall` et al., possibly even combine them into a single non-generic `MethodCall` type, then translate that simpler API into a generic, type-safe API in the newly added types.
Instead of forwarding the API types' various `Callback` methods to the corresponding `Callback` methods, which delegate to `SetCallbackWith- Arguments` and `SetCallbackWithoutArguments`, combine the latter into a new uniform method `SetCallbackResponse` and let the API types call that one directly.
This subclass of `MethodCall` was previously only needed for its specially typed `Callback` method. This method was part of the fluent API, which has now been separated into new dedicated types.
Instead of forwarding the API types' various `Raises` methods to the corresponding `Raises` methods, which delegate to `RaisesImpl`, rename the latter to `SetRaiseEventResponse` and delegate to those directly.
This class has become practically identical with its base class `MethodCall` when its fluent API `Raises` methods were removed. Use the non-generic base class directly.
stakx
force-pushed
the
non-generic-methodcall
branch
from
f4297db
to
bc7ea6f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is achieved by separating the fluent API (which relies heavily on the type system and generics) from the actual implementation code. Fluent API methods are moved into generic types in the
Moq.Language.Flownamespace. These new types wrapMethodCalls and implement the fluent API interfaces.MethodCallet al. then no longer need to implement those, nor need they be generic anymore.Getting rid of generics in the
MethodCalltypes should allow us to apply optimizations, de-duplications and code simplifications much more easily because static types won't get in the way needlessly everywhere.This benefit can be seen already by the removal of two redundant
MethodCalltypes:MethodCall<T>andSetterMethodCall<T, TProperty>, both of which were essentially duplicates ofMethodCall.