-
Notifications
You must be signed in to change notification settings - Fork 27
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
Interception of inherited methods (e.g. GetHashCode) #30
Comments
Yes it is intentional. See 535917e IIRC: Before GetHashCode etc. used the default implementations of System.Object and didn't forward it to the object. Which I consider the correct behavior. What makes it slower in your case? Do you have an interceptor that takes a long time or is it also a large penalty if you intercept using an interceptor that does nothing at all? |
Just verified: If intercepting with an interface proxy the following class
the proxy will return anything but 42 as HashCode without that change. |
Yep, I have slow interceptor. I found that GetHashCode is being called many times inside NInject's cache. I put workaround inside my interceptor: I check what method is being called. I copied ShouldIntercept(methodInfo) from: This lead to other question: why it differs in behavior from the case with InterceptAttribute placed on the class? Before I could use both methods interchangeably, now I need special Interceptor. |
Ok, I understand: attribute is on the class, and my interceptor is on the interface. I can live with that but... what was rationale behind that decision? Maybe it should be optional i.e.
|
I use master on production because of #26 (thanks again) and I encountered another problem with method interceptors applied manually e.g.:
They intercept not only public methods of Bar, but also inherited (Equals/GetHashCode). It's not the case when interception is applied via InterceptAttribute. And it's also differs from "official" 3.0.0.8 NuGet package.
See full example here:
https://gist.github.com/orient-man/9625459
In my use case this leads to large performance penalty. I'm not sure if this change is intentional.
The text was updated successfully, but these errors were encountered: