Add support for default interface members in inheritance-based proxy types #661
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
stakx
commented
Aug 31, 2023
src/Castle.Core/DynamicProxy/Contributors/ClassProxyTargetContributor.cs
Show resolved
Hide resolved
src/Castle.Core/DynamicProxy/Contributors/InterfaceMembersWithDefaultImplementationCollector.cs
Outdated
Show resolved
Hide resolved
src/Castle.Core/DynamicProxy/Contributors/InterfaceMembersWithDefaultImplementationCollector.cs
Outdated
Show resolved
Hide resolved
src/Castle.Core/DynamicProxy/Contributors/InterfaceProxyWithoutTargetContributor.cs
Show resolved
Hide resolved
src/Castle.Core/DynamicProxy/Contributors/InterfaceProxyWithoutTargetContributor.cs
Show resolved
Hide resolved
stakx
force-pushed
the
enhancements/default-interface-members
branch
from
001f261
to
41ebbcc
Compare
stakx
commented
Sep 1, 2023
stakx
force-pushed
the
enhancements/default-interface-members
branch
from
41ebbcc
to
f06e648
Compare
stakx
changed the title
|
@jonorossi, I think I've finally got this in a reasonably understandable & mergable state. I'd appreciate if you could give this at least a cursory review, if you can spare some time. As noted in the initial description above, this is only for proxies without targets, and I am not testing all possible combinations of DynamicProxy features. Do let me know if you think I have missed any crucial test cases. Regarding the structure of this PR: most of the commits consist simply of new tests (usually grouped by some aspect listed in the PR's description). Most of those actually pass right away, without any code changes. In the few cases where tests don't pass, the test-only commit is immediately followed by one that makes them succeed. Those actual-code-change commits are sometimes followed by a little refactoring & clean-up work. |
Open
... instead of `MethodBase`s to identify which methods get invoked. This should make tests easier to read & understand.
Two of these tests are failing: * Class proxies cannot intercept interface methods with a default implementation if the proxied class type does not override it. * Interface proxies cannot proceed to default implementations.
A class implementing an interface with default method implementations will not necessarily override those methods; in such cases, the methods are currently "invisible" to DynamicProxy and thus won't get proxied. This can be solved by an extra pass over all interfaces to collect such methods, as is done in this commit. Ideally we wouldn't have to iterate over all interfaces more than once, so we should next make an effort to limit the runtime impact of this extra pass.
Assuming that default interface methods are relatively rare, if we keep track of which interfaces contain any of them at all, we can then limit our extra pass during class proxy generation to just those interfaces and exclude the rest (i.e. hopefully the majority). Additionally, our collector may skip some of the more expensive checks by bailing out for methods it isn't actually interested in.
... by properly forwarding the "standalone" flag in the newly added collector.
Those essentially target "mixed" scenarios where default implementations show up next to "regular" methods. This is to better ensure that the new code paths will not interfere with pre-existing logic.
The code changes we made do not suggest that pre-existing logic dealing with generics might somehow no longer work, however we did add a bit of new code for generics which we should target with at least one test.
This includes a test for `static abstract` methods that remains ignored for now, since we haven't implemented support for this C# 11 language feature, nor do we target any runtimes that support it. (The test is being added as a future reminder, once we start targeting .NET 7+.)
A few of these tests fail due to `Debug.Assert` failures in `Interface- MembersWithDefaultImplementationCollector`.
`sealed` methods do not show up in interface mappings, so make sure `InterfaceMembersWithDefaultImplementationCollector` can deal with them anyway in case of interfaces that contain both `sealed` methods as well as overridable ones with a default implementation.
stakx
force-pushed
the
enhancements/default-interface-members
branch
from
f06e648
to
51112db
Compare
jonorossi
approved these changes
Oct 25, 2023
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 another step towards completing #447. I'm limiting this PR to inheritance-based proxy types (i. e. those without target) due to time constraints – having to adjust only 2 out of 5 implementations is a lot less work! – and because these are likely the most important proxy types for downstream testing libraries such as Moq, NSubstitute, etc.
protected,)protected internal,internalstaticmembersstatic abstractmembersTesting all possible combinations of these aspects would be prohibitive, I've therefore restricted tests to a subset of these combinations that seemed reasonable and justifiable by the nature of the actual code changes / extensions made to DynamicProxy.