And how about generic methods? Basically the question is - do we cache based on generic method definition or based on closed generic method, in which case foo.Bar<int>() and foo.Bar<string>() are considered different and each gets its own caching, and selector is called each time the method is called with new generic parameter.
My opinion is, it'd be an overkill. It has more downsides than upsides, and its usfullness is really limited. Krzysztof >>> [email protected] 2008-12-23 13:03 >>> 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 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 -~----------~----~----~----~------~----~------~--~---
