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]> > > > > >>>>>>> . > > >>>>>>> > 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]> > > > > >>>>>>> . > > >>>>>>> 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]> > . > > >>>>>> 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 > > > > ... > > > > 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.
