-
Notifications
You must be signed in to change notification settings - Fork 263
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
Add protected BaseResult()
method to CallInfo.
#641
base: main
Are you sure you want to change the base?
Conversation
@dtchepak I'm a bit out of context after absence and need more time to ramp up 😊 A couple of questions. |
I don't think it is possible to distinguish partial mocks statically using our API. 😞
I'm still not sure on this all these years later! 😂 Leaving partial mocks out of this for the moment, I think it makes sense to be able to access the base value from within the |
@tpodolak Will this change to use |
Would like to see this merged in as I need this functionality too |
I think it might. Analyzers do some check against |
@tpodolak |
@dtchepak I've built your branch and run analyzers against that and as expected,
Thanks, I've seen that, however this still breaks current CallInfo alayzers. I will fix analyzers part once this is merged and published to NuGet or some private feed |
Thanks @tpodolak . Is it possible to support both? Or will different NSub versions require different Analyzer versions? |
@zvirja Are you OK with this change? If you don't have time to look at it please let me know. 😄 |
It is possible to support both versions with just one version of analyzers. Here are necessary chagnes nsubstitute/NSubstitute.Analyzers#158 |
Hi @dtchepak! Hope you are doing fine and are not annoyed too much that I'm not replying timely 😖 I actually have a bit of concerns regarding the newly introduced In order to enhance that I actually was planning to revisit it the next major version. The idea was that we e.g. have public interfaces for things like The motivation is that we could modify Same for consumption - if you consume anything from Not sure whether you share my vision on this. Library is really small, so such kind of things might be an overkill. But somehow I see a beauty and usefulness in that, as we are just a few tiny steps from there. |
Of course not annoyed! We're all volunteers here, I am grateful for any reply!
Would you be happier if I change this PR to expose interfaces for these? Alternatively we could take this as-is (if you are happy enough with the implementation) and do the larger change to interfaces in a separate issue? We should also be mindful that any change along these lines will probably make a lot of work for the @tpodolak and the Analyzers project. |
Hi @dtchepak,
Yes, I think it would be nice to start with interfaces approach for new features, so later we could rework other features to catch-up. This way we can also see how it looks like. |
Apply review comments.
102eccc
to
ab6733c
Compare
Create CallInfo<T> to calls that return results and expose `BaseResult`. This gets messy to push the generic all the way through the code, so am just using a cast in `Returns` extensions to handle this. This should be safe as if we are in `Returns<T>` then the return value should be safe to cast to a `T`. Based off discussion here: nsubstitute#622 (comment)
Apply review comments.
ab6733c
to
b89b34e
Compare
@zvirja I've attempted to extract I'm a bit concerned about the |
@dtchepak I've gave it a brief look and before we proceed further, I can see that we introduce a lot of breaking changes to API (as use now use interface instead of implementation). I'm afraid that it could break other libraries (like AutoFixture) which might depend on these APIs. Should we then consider branching out Then we could add a couple of other improvements we planned to add. |
Thanks @zvirja. We are fine for next release to be |
Create CallInfo to calls that return results and expose
GetBaseResult
.This gets messy to push the generic all the way through the code, so am
just using a cast in
Returns
extensions to handle this. This should besafe as if we are in
Returns<T>
then the return value should be safe tocast to a
T
.Based off discussion here:
#622 (comment)