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 > > > > > > > > >
-- Cheers, hammett http://hammett.castleproject.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
