-
Notifications
You must be signed in to change notification settings - Fork 122
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
Allow type-safe calls to be used in InOrder #78
Conversation
This modifies `InOrder` to receive variadic `any` instead of `*Call`, allowing users to use this function with type-safe generated Calls. This implementation uses a type assertion to check if the provided arguments are `*Call`s or reflection to get the `*Call` when the arguments wrap one (generated code). If neither of the two cases are fullfiled then that argument is ignored. Fix #70.
Would it make sense to panic? Today it's not possible to pass an invalid call to |
Alternatively, what about a type-safe(r) way of doing this: Having |
This make `InOrder` to panic when any of its arguments isn't either a `*Call` or a mock generated type which should already embed `*Call`.
This adds to the panic message the index and type of the first invalid type (if any) passed as parameter to `InOrder`.
Tested in quic-go in quic-go/quic-go#4057. Seems to work. I also tested that it panic if I pass things other than gomock calls to 🚢 it! |
This breaks I can see it was previously proposed using an interface that implements a particular method instead. That would also be sensible. Perhaps this route could be revisited. |
This modifies
InOrder
to receive variadicany
instead of*Call
, allowing users to use this function with type-safe generated Calls.This implementation uses a type assertion to check if the provided arguments are
*Call
s or reflection to get the*Call
when the arguments wrap one (generated code). If neither of the two cases are fullfiled thenInOrder
panics.Fix #70.