I'd appreciate other opinions on the matter btw 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]> >>>>> . >>>>> > 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 >>>> [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 >>> [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 >> [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 > [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 [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
