I like the second one. Any need to pass a second parameter when you actually pass the component model and this it's writable collection of interceptors? I would pass only the model and document explicitly not to modify its collection but instead return the merged collection back.
2010/3/12 Krzysztof Koźmic (2) <[email protected]> > Order of insertion most likely > > On 12 Mar, 09:40, Ayende Rahien <[email protected]> wrote: > > Yes > > Although I am not sure what you would be sorting on > > > > 2010/3/12 Krzysztof Koźmic (2) <[email protected]> > > > > > so we basically have now the following two suggestions (in > > > pseudocode): > > >http://gist.github.com/330162 > > > > > correct? > > > > > On 12 Mar, 09:06, Ayende Rahien <[email protected]> wrote: > > > > Note; answering the entire thread. > > > > > > The original reason behind IModelInterceptorsSelector was that we > needed > > > to > > > > make dynamic decisions about some piecesof code. In particular, > whatever > > > > transactions were active or not. > > > > The design at the time called to allow the IModelInterceptorsSelector > to > > > > totally replace the default interceptors, and I would like to keep > that > > > as > > > > an option. > > > > Regarding the operation mode, I agree that using the return value is > > > clearer > > > > than a method that is expected to modify its arguments. I would > actually > > > go > > > > further than that and say that we need to pass a readonly collection > to > > > that > > > > method. Not a modifable one. > > > > When the docs say that you merge the model.Interceptors with what the > > > > selector returns, it means that you merge them and _return the merged > > > > value_. > > > > > > 2010/3/11 Simone Busoli <[email protected]> > > > > > > > sure, I will prepare one for a real case I'm on now. > > > > > > > 2010/3/11 Krzysztof Koźmic <[email protected]> > > > > > > >> the way I understand it you want to create a single empty > collection > > > of > > > > >> interceptors, and pass it to each selector in turn. > > > > >> This means that subsequent selectors can see, and override choice > made > > > by > > > > >> previous one, which breaks independence of selectors. > > > > > > >> I really feel we should discuss a real example at this point. > > > > > > >> Krzysztof > > > > > > >> On 3/11/2010 8:16 AM, Simone Busoli wrote: > > > > > > >> I think all your considerations are well satisfied by a void > return > > > method > > > > >> which modifies the existing collection in any way it wants. > > > > >> If you don't like modifying method arguments then we could pass in > a > > > > >> delegate. > > > > > > >> 2010/3/11 Krzysztof Koźmic <[email protected]> > > > > > > >>> we've been relying on order to do decorators, with quite good > > > results. > > > > >>> We're cutting edge here, we give people scissors. > > > > > > >>> Current design keeps selectors independent, which I consider to > be a > > > good > > > > >>> thing. > > > > >>> You don't have to have just one selector if you need so. I > expressed > > > my > > > > >>> personal preference, nothing more. I would use more than a single > > > selector > > > > >>> if I felt a need with no hesitation. > > > > >>> Also current design does not put any requirements at you WRT > > > > >>> model.Interceptors. > > > > > > >>> Perhaps it would be more beneficial if we moved from abstract > concept > > > to > > > > >>> some actual example where you feel having that capability (single > jar > > > of > > > > >>> interceptors passed between all selectors) would be required. > > > > > > >>> cheers, > > > > >>> Krzysztof > > > > > > >>> On 3/10/2010 10:53 PM, Simone Busoli wrote: > > > > > > >>> I see selectors as a step in the pipeline where you can apply > > > > >>> additional concerns, you don't care about what's already there, > you > > > just add > > > > >>> behavior if necessary. > > > > >>> That's why I don't think there should be only 1 selector and why > a > > > > >>> selector shouldn't care about the stuff that's already in > > > > >>> model.Interceptors. That's why I'm saying we're probably looking > at > > > things > > > > >>> under a different perspective. > > > > > > >>> About order of registration for selectors, I think it's a very > bad > > > way > > > > >>> of doing things. To me the order of two calls to > container.Register > > > (or most > > > > >>> of what else you could put into the container: facilities, > > > interceptors,...) > > > > >>> should mean as much as the order of two fields in a class. > > > > >>> If you're relying on that you're looking for troubles. > > > > > > >>> 2010/3/10 Krzysztof Koźmic <[email protected]> > > > > > > >>>> On 3/10/2010 10:37 PM, Simone Busoli wrote: > > > > > > >>>> inline > > > > > > >>>> 2010/3/10 Krzysztof Koźmic <[email protected]> > > > > > > >>>>> On 3/10/2010 10:15 PM, Simone Busoli wrote: > > > > > > >>>>> 2010/3/10 Krzysztof Koźmic <[email protected]> > > > > > > >>>>>> On 3/10/2010 9:59 PM, Simone Busoli wrote: > > > > > > >>>>>> inline > > > > > > >>>>>> 2010/3/10 Krzysztof Koźmic <[email protected]> > > > > > > >>>>>>> you put interceptors in whatever order you please. > > > > > > >>>>>> how? > > > > > > >>>>>> You create the array yourself in the selector. You choose > what to > > > put > > > > >>>>>> there, and in what order. it doesn't even have to have > anything in > > > common > > > > >>>>>> with componentModel.Interceptors collection > > > > > > >>>>> Can you see that all interceptors in model.Interceptors are > > > appended > > > > >>>>> after those selected by all selectors? > > > > > > >>>>> Yes, I can see that. I would execute that code only when no > > > selector > > > > >>>>> has opinion about component model in question. > > > > > > >>>> I'm not sure that would be a good choice, but we definitely > need to > > > > >>>> define what selectors are for. In my opinion they should have a > > > chance to > > > > >>>> modify the existing collection of interceptors. If they don't > care > > > about the > > > > >>>> order then they will eventually append their stuff otherwise > they > > > will do > > > > >>>> nothing. With the current code we're really looking for bugs > with > > > duplicate > > > > >>>> interceptors appended at the end. > > > > > > >>>> Why wouldn't this be a good choice? > > > > > > >>>> Either selectors want to override the choice, or we go with > default. > > > > >>>> Should work IMO. > > > > > > >>>>>>> between selectors order of selectors transfers to order of > > > > >>>>>>> interceptors. Plus I think you should not have multiple > selectors > > > for > > > > >>>>>>> one model so it's a non-issue anyway. > > > > > > >>>>>> why? I'm using multiple selectors to apply different and > > > unrelated > > > > >>>>>> concerns to models. Do you think I should centralize a bunch > of > > > unrelated > > > > >>>>>> stuff into the same class? > > > > > > >>>>>> Give me a scenario. But despite of it, doesn't order of > selectors > > > > >>>>>> give you enough control? > > > > > > >>>>> A selector handling whether we need to add transaction > interceptor > > > > >>>>> and another handling exception-related stuff. > > > > >>>>> Ideally I wouldn't like to depend on the order of selectors and > put > > > > >>>>> that logic in the selectors themselves, for instance, > transaction > > > > >>>>> interceptor should be last. (in this I would like to extend > > > > >>>>> InterceptorReferenceCollection to support keeping an > interceptor in > > > a > > > > >>>>> certain position even if other interceptors are added later) > > > > > > >>>>> now we're talking :) > > > > >>>>> I still think that you can achieve this with ordering of > selectors > > > > >>>>> without changing the interface. Plus you always can use > > > IInterceptorSelector > > > > >>>>> to select/order interceptors at a method level. > > > > > > >>>> Would you be confident in relying on the order in which you > > > register > > > > >>>> your selectors? I'd prefer to let the selector itself decide > where > > > to put > > > > >>>> its interceptor/s. > > > > > > >>>> I think I would 99% of the time. And for the remaining 1% I'd > use > > > > >>>> IInterceptorSelector. > > > > > > >>>>>>> in addition I'm against passing interceptors selected by one > > > > >>>>>>> selector, > > > > >>>>>>> to subsequent selectors. > > > > > > >>>>>> this is the current code. how do you apply order? how do you > > > remove > > > > >>>>>> interceptors? > > > > > > >>>>>> foreach(IModelInterceptorsSelector selector in > selectors)// > > > > >>>>>> selectors are asked in order you register them in > > > > >>>>>> { > > > > >>>>>> InterceptorReference[] interceptors = > > > > >>>>>> selector.SelectInterceptors(model); > > > > > > >>>>>> + if (interceptors == null) > > > > >>>>>> + { > > > > >>>>>> + continue; > > > > >>>>>> + } > > > > >>>>>> + > > > > >>>>>> + foreach (InterceptorReference interceptor in interceptors) > > > > >>>>>> + yield return interceptor; // interceptors are returned in > order > > > > >>>>>> selector put them in the array > > > > >>>>>> } > > > > >>>>>> + > > > > >>>>>> + foreach (InterceptorReference interceptor in > model.Interceptors) > > > > >>>>>> + yield return interceptor; > > > > >>>>>> } > > > > > > >>>>>> Note that model.Interceptors are concatenated to anything > > > returned > > > > >>>>> by selectors, so you don't have control unless you modify the > > > collection > > > > >>>>> directly. > > > > > > >>>>>>> 2010/3/10 Simone Busoli <[email protected]>: > > > > >>>>>>> > Except that I don't agree with this principle, the return > > > value > > > > >>>>>>> doesn't let > > > > >>>>>>> > you specify where exactly to put the interceptor. So the > return > > > > >>>>>>> value > > > > >>>>>>> > provides a subset of the functionality provided by the > input > > > > >>>>>>> collection. > > > > > > >>>>>>> > 2010/3/10 Krzysztof Koźmic <[email protected]> > > > > > > >>>>>>> >> void methods should not modify their arguments > > > > > > >>>>>>> > -- > > > > >>>>>>> > You received this message because you are subscribed to > the > > > > >>>>>>> Google Groups > > > > >>>>>>> > "Castle Project Users" group. > > > > >>>>>>> > To post to this group, send email to > > > > >>>>>>> [email protected]. > > > > >>>>>>> > To unsubscribe from this group, send email to > > > > >>>>>>> > [email protected]<castle-project-users%[email protected]> > <castle-project-users%[email protected]<castle-project-users%[email protected]> > > > > > <castle-project-users%[email protected]<castle-project-users%[email protected]> > <castle-project-users%[email protected]<castle-project-users%[email protected]> > > > > > > > > >>>>>>> . > > > > >>>>>>> > For more options, visit this group at > > > > >>>>>>> >http://groups.google.com/group/castle-project-users?hl=en. > > > > > > >>>>>>> -- > > > > >>>>>>> You received this message because you are subscribed to the > > > Google > > > > >>>>>>> Groups "Castle Project Users" group. > > > > >>>>>>> To post to this group, send email to > > > > >>>>>>> [email protected]. > > > > >>>>>>> To unsubscribe from this group, send email to > > > > >>>>>>> [email protected]<castle-project-users%[email protected]> > <castle-project-users%[email protected]<castle-project-users%[email protected]> > > > > > > ... > > > > więcej >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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-users?hl=en.
