I like the "ref IInterceptors[]". The comments I made about needing the FieldInfo was to do with reading/writing the interceptors from the generated field, but this isn't needed since you are passing a ref of the field to AbstractInvocation.
Hammett said the following: > re-proxying a type for different scenario (logging + atm) I thought he was referring to the ability of getting the interceptor selector to be called again so you can reselect the interceptors the a proxy. However, I probably misunderstood what he meant by this. On Tue, Dec 23, 2008 at 6:11 PM, Krzysztof Kozmic <[email protected]>wrote: > > Hi > > As for your concerns. > > 1. AbstractInvocation whould _not_ know about the field. The > AbstractInvocation's code could be similar to this: > > protected AbstractInvocation( > object target, object proxy, IInterceptor[] interceptors, > Type targetType, MethodInfo targetMethod, object[] > arguments, > ref IInterceptor[] methodInterceptors, IInterceptorSelector > selector) > { > Debug.Assert( selector != null, "if this .ctor is called > selector must exist" ); > if (methodInterceptors == null) > { > methodInterceptors = selector.SelectInterceptors( > targetType, targetMethod, interceptors ) ?? new IInterceptor[0]; > } > > this.proxy = proxy; > this.target = target; > this.interceptors = methodInterceptors; > this.targetType = targetType; > this.targetMethod = targetMethod; > this.arguments = arguments; > } > > all AbstractInvocation knows about is that it gets a ref IInterceptor[] > parameter. I think it's cleaner than passing whole cache, and then > havign to do lookup. > > 2. Why would we want to clean the cache? Can you give an example of a > scenario that would require that? > 3. I don't think I understand the last part. The one about using > reflection to get FieldInfo. Are you still referring to the clear cache > scenario? > If not, and you're referring to passing methodInterceptors to generated > type derived from AbstractInvocation, I don't understand why you need > FieldInfo for? > You don't need to pass fieldInfo, but field reference. So the field > could be created and only used in the method that generates overriden > method. > > Krzysztof > > >>> [email protected] 2008-12-23 03:17 >>> > As Krzysztof has mentioned the cache has to be per instance. I > mentioned > earlier just using a dictionary in the proxy because I thought it would > keep > the proxy neater, but having a field for each method may be better (I'm > not > sure how much faster it would make it). However, it means that the > AbstractInvocation needs to write to each field instead of being passed > a > simple cache object. Clearing the cache has to know about each field > for > each MethodInfo, but that might not matter depending on where the > clear > cache method is provided. If we went with an interceptors field for > each > method wouldn't that mean that the code generation of the method would > have > to be changed to pass this field to the IInvocation, otherwise you have > to > use reflection to get the FieldInfo (which could be cached but > complicates > things more)? > > > 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. > > > > > -- Jonathon Rossi --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
