yes, you can get the patch I put on donjon and see the tests. hammett pisze: > Do your changes enable this scenario? > > On Wed, Dec 17, 2008 at 10:00 AM, Krzysztof Koźmic > <[email protected]> wrote: > >> For my particular needs, it's like you describe it. >> I wanted to plug in different interceptors (like logging and different >> precondition checking) for different intercepted methods. >> So that I no longer need to start my Intercept method with >> >> if(someCriteriaOfIInvocation != false) >> >> Krzysztof >> hammett pisze: >> >> Maybe we need to clarify the scenarios that driven the need for the >> selector. Originally I thought about typical aop definitions of >> aspects and pointcuts. An implementation of selector could read this >> configuration and return the right interceptors for each pointcut. >> >> Fabian/Krzysztof, what are your needs for it? >> >> >> On Wed, Dec 17, 2008 at 7:13 AM, Krzysztof Kozmic <[email protected]> >> wrote: >> >> >> Hi, >> >> answer below >> >> Now: >> var options = new ProxyGenerationOptions (); >> options.Selector = selector; >> X x = (X) generator.CreateClassProxy (typeof (X), options, myInterceptors); >> >> Then: >> var selectingInterceptor = new SelectingInterceptor (myInterceptors, >> selector); >> X x = (X) generator.CreateClassProxy (typeof (X), selectingInterceptor); >> >> Why is this hackish or adds complexity? >> >> I remove: >> - the requirement of a static or instance field (+ initialization) >> re: I think static would be better, then you pay the price of initialization >> only once >> >> - the requirement of having IInterceptorSelector in the >> ProxyGenerationOptions (+ serialization, + Equals, + GetHashCode) >> re: but I think PGO is where it belongs. Also if we codegen it, it would >> work slightly faster at runtime (no need to lookup the methodInfo, then >> lookup interceptors for the method) Also code for serialization and Equals >> and GHC is already there :) >> >> Another thing is, that it'd be awkward: you'd have an array of interceptors >> in the proxy type, but keep only one interceptor in it, and all the call >> next logic would be duplicated in it. >> It also adds an implicit contract: put any interceptors you like into the >> CreateClassProxy, or if you want to select some of them, wrap them with >> SelectingInterceptor. This is the kind of implicit contracts I hate Unity >> for. >> We might add an overload that takes just a single SelectingInterceptor but I >> don't like the idea of adding another overload to every CreateXYZProxy >> method. >> >> From current implementation' perspective, your idea certainly introduces >> less changes (virtually none, if we ditch the add-overloads idea), but in a >> longer perspective, I think Selector on ProxyGenerationOptions would work >> better. >> Also, sole implementation of SelectingInterceptor would be more complicated >> than adding support for IInterceptorSelector via code gen. >> >> what do others think? is there a third way? >> >> Best regards, >> 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 -~----------~----~----~----~------~----~------~--~---
