WIP: Forward non-intercepted methods on class proxies to target#450
WIP: Forward non-intercepted methods on class proxies to target#450stakx wants to merge 3 commits intocastleproject:masterfrom
Conversation
src/Castle.Core/DynamicProxy/Contributors/WrappedClassMembersCollector.cs
Outdated
Show resolved
Hide resolved
The (failing) test being added here specifies that if one chooses via `IProxyGenerationHook.ShouldInterceptMethod` not to intercept a method then invocations of that method on the proxy should be forwarded to the target object (if present).
stakx
force-pushed
the
forward-nonintercepted-methods-to-target
branch
from
1cafbc2 to
7228bf7
Compare
src/Castle.Core/DynamicProxy/Contributors/WrappedClassMembersCollector.cs
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
Methods which are filtered out by `MembersCollector` (e.g. because the hook's `ShouldInterceptMethod` returned false) are hereby made visible to the proxy-class-with-target generator. Some methods must still be excluded: `ForwardingMethodGenerator` does not perform any accessibility checks, so we need to check whether the target method is callable "from the outside". For most cases, a simple `method.IsPublic` check suffices, however we might want to test if the target method is callable through an interface.
stakx
force-pushed
the
forward-nonintercepted-methods-to-target
branch
from
7228bf7 to
3ae08b8
Compare
stakx
changed the title
|
Once again, this is going to take more work than anticipated. What is needed here is a utility method that checks accessibility of a member (Also, we might be able to reimplement I'll ping you once I'm done. |
Haha, as always with DP.
👍 |
|
@stakx how about this one? |
|
Same here. I'll eventually get back to it. |
2 participants
This should resolve #67.
(At least as far as is possible: non-interceptable methods such as non-virtual, sealed, or private methods of course still cannot be forwarded to the proxy.)