Hi, inline
>>> [email protected] 2008-12-16 16:32 >>> Hi! > The way I implemented it now (you can see the patch here: > http://support.castleproject.org/projects/DYNPROXY/issues/view/DYNPROXY-ISSUE-37) > is that interceptorSelector is an instance field on proxy that is passed via > .ctor > I'm thinking if it should be this way. Preferably, I'd have it be static. > 1. First of all, InterceptorSelector, being part of the > ProxyGenerationOptions is the part of CacheKey, so by definition if it > changes, a new proxy type will get generated. As long as it's identical, each > call to GenerateProxyTypeXYZ will return the same type. > Moreover, since it's already part of ProxyGenerationOptions, which gets set > as a static field on proxy type, there's no need for separate field for > InterceptorSelector at all. > Anytime it's needed, it can be retrieved from ProxyGenerationOptions instance. > It also removes any need to add code to serialize or deserialize it. Definitely, the way Hammett originally devised it (with the selector being part of the ProxyGenerationOptions), it is attached to the type, not the instance. I think so as well, I was mislead by Hammett's note in the bug report, that a new ctor whould have to be implemented, and as a result of that I implemented it as instance field, which is am certain now, was not the best way to go. In fact, I think it might have been meant to influence code generation rather than the actual runtime, although I can't be sure. By "influence code generation" I mean that the code generator would call the respective selector methods to decide which of the interceptors to use for each virtual method on the proxied class. It would explicitly generate code to call that specific interceptor. If no interceptor was returned, no override would be generated (unless it was abstract or an interface method, in which case a NotImplementedException could be thrown). That would make for very efficient selective interception (and would avoid overrides for methods that aren't interesting). And you could always implement an instance-based interceptor-selector easily yourself anyway. Just create a compound interceptor that delegates to specific inner interceptors... The more I think of it, the more convinced I am that this is what it was meant to be. Hammett - can you comment on this? You can't do that. Simple reason is, that you don't get access to interceptors while generating proxy type, ergo you can't call selector on them, ergo it has to be done at runtime. (Serialization code would still be needed - but only in the ProxyGenerationOptions, not in the generated code.) Yes, I meant that I wouldn't have to add any code to handler serialization, as it would be handled by serializing ProxySerializationOptions. Krzysztof Regards, Fabian CONFIDENTIALITY NOTICE This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged, confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please delete all copies of this message and notify the sender immediately by return mail or fax ATSI S.A.(+4812) 285 36 04. Any email attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
