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