> In generation time you can have access to a selector, that's why I > added to options. It was intended to drive the methods that would be > proxy, even to skip the ones that wouldn't. > > When I was planning the implementation of this, I realized how this > could be problematic for simple windsor scenarios. So I gave up > implementing the selector at all. I can't remember all the reasons, > but it should come once you consider all aspects: > - proxying a type for the first time (scenario 1) > - re-proxying a type for different scenario (logging + atm) > - new container on same appdomain, reproxying > - serialization/deserialization of proxy
So, you'd say selection of methods at code generation time doesn't make sense for us anyway? I'm not sure. It would make a nice feature, I think, but if nobody would actually use it... The problem is that a runtime-based selection won't give us any benefits over simply using a delegating interceptor, but it does complicate code generation and ProxyGenerationOptions. I'd vote for providing an out-of-the-box delegating interceptor rather than adding this to the codegen _if_ we decide to only support this scenario. (Even though Kryzstof has already implemented it; maintainance, tests, etc. would be much easier with a delegating interceptor than otherwise.) Fabian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
