Fabian Schmied pisze: > Hi Krysztof! > > First, thanks a lot for implementing this feature, it has been on the > list for a long time now... > > Regarding your questions: > > >> 1. as I described it in b) >> > > I think that's the way I would expect it to work, too. > > >> 2. calls are cached the first time a method is called >> > > That's better for performance, I guess. I wonder whether we would want > to enable "re-selection" of interceptors... > Well, at a later time maybe. > > Yeah, it might be useful but it's not as high priority as few other outstanding things IMHO >> 3. when empty array is returned either target implementation is called >> directly, or (when called for method without target implementation, >> like abstract method or interface) a NotImplementedException is >> thrown. >> Also when calling target method directly a check for leaking this is >> being made if necessary, and if target is returned, method returns >> reference to proxy instead. >> > > Hm, is this a general fix for the "leaking this" problem or have you > implemented it only in combination with IInterceptorSelector? I'm not > sure what was already planned/implemented about this feature. Hammett, > anyone? > Nope, this is not a general fix, although I'd be happy to extend it. For now it only checks the return value of target method when it's called directly. It does not (yet) check the out or ref parameters. The question is however, how far do we want to go with it. AFAIK with current version of the CLR we can never get 100% protection agains leaking this, since we only operate on method boundary. Inside, the method can leak 'this' in a myriad of ways, by seting it to some global variable, or by returning 'this' as a member of a member of a member of return class. So, the question is, how, what, and how deep do we want to check for the leaks. My $0.02 is that we can't do pretty much anything about global variables, and members of a member can be checked by interceptor if user really needs it, so I'd only check the return value and ref\out parameters. > >> 4. Serialization is handled the following way: I didnt add any code to >> serialization, for deserialization only the InterceptorSelector is >> obtained from ProxyGenerationOptions. This way the information about >> cached interceptors is being lost, but it should be recreated when >> method is called again, so no loss here, at least I don't see one. >> > > I can't really say anything about that without checking out the code, > however I think it's no problem if the InterceptorSelector is called > again after deserialization; after all, the caching should only be > seen as a performance thing, not be relied upon. > > >> 5. I removed the UseSelector property. >> > > Good thing :) > > >> the patch is here: >> http://support.castleproject.org/projects/DYNPROXY/issues/view/DYNPROXY-ISSUE-37 >> > > As usually, I'm slightly swamped at work (and ATM I don't have access > to my dev environment), so I'm not sure whether I'll be able to look > into it any time soon; however, if noone else volunteers, I promise to > have a look as soon as my time permits. Thanks a lot for making this > work! > > Best regards, > Fabian > Krzysztof
--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
