This repository has been archived by the owner on Jun 30, 2023. It is now read-only.
Allow modifying method invocation return values #61
Labels
enhancement
New feature or request
Comments
|
I originally voted towards I was wondering whether it could be implemented as a |
|
Yeah, making it a record sounds good. I'll see how that looks 👍. Will need IsExternalInit to keep it NS2, but it should just work... |
|
Works like a charm :)
|
kzu
added a commit
that referenced
this issue
Dec 21, 2020
Otherwise extenders would need to implement the (mostly trivial) class themselves, which doesn't add value and is just friction. All our other interfaces have public implementations anyway.
We make the class a record too, so it can easily be modified on the fly with `result with { Exception = ..., ReturnValue = ... }`, for example.
Fixes #61.
kzu
added a commit
that referenced
this issue
Dec 21, 2020
Otherwise extenders would need to implement the (mostly trivial) class themselves, which doesn't add value and is just friction. All our other interfaces have public implementations anyway.
We make the class a record too, so it can easily be modified on the fly with `result with { Exception = ..., ReturnValue = ... }`, for example.
Fixes #61.
kzu
added a commit
that referenced
this issue
Dec 21, 2020
Otherwise extenders would need to implement the (mostly trivial) class themselves, which doesn't add value and is just friction. All our other interfaces have public implementations anyway.
We make the class a record too, so it can easily be modified on the fly with `result with { Exception = ..., ReturnValue = ... }`, for example.
Fixes #61.
kzu
added a commit
that referenced
this issue
Dec 21, 2020
Otherwise extenders would need to implement the (mostly trivial) class themselves, which doesn't add value and is just friction. All our other interfaces have public implementations anyway.
We make the class a record too, so it can easily be modified on the fly with `result with { Exception = ..., ReturnValue = ... }`, for example.
Fixes #61.
kzu
added a commit
that referenced
this issue
Dec 21, 2020
Otherwise extenders would need to implement the (mostly trivial) class themselves, which doesn't add value and is just friction. All our other interfaces have public implementations anyway.
We make the class a record too, so it can easily be modified on the fly with `result with { Exception = ..., ReturnValue = ... }`, for example.
Fixes #61.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It would be useful to be able to modify the returned values from a call to the base method implementation or the subsequent behaviors in the pipeline before returning to caller.
Currently,
IMethodReturnhas no public implementation and no mutating members that can be used for that, so it's pretty much forbidden (unless you implement the interface yourself).We could either make the internal
MethodReturnimplementation public (like we do forMethodInvocationitself and/or add mutating methods likeWithArguments,WithReturnValueandWithException. Since almost all our interface implementations are public, maybe that's the simplest approach here too?From feedback by @stakx in #56
The text was updated successfully, but these errors were encountered: