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]
<mailto:[email protected]>>
Order of insertion most likely
On 12 Mar, 09:40, Ayende Rahien <[email protected]
<mailto:[email protected]>> wrote:
> Yes
> Although I am not sure what you would be sorting on
>
> 2010/3/12 Krzysztof Koźmic (2) <[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>>
>
> > > > sure, I will prepare one for a real case I'm on now.
>
> > > > 2010/3/11 Krzysztof Koźmic
<[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>>
>
> > > >>>> On 3/10/2010 10:37 PM, Simone Busoli wrote:
>
> > > >>>> inline
>
> > > >>>> 2010/3/10 Krzysztof Koźmic
<[email protected]
<mailto:[email protected]>>
>
> > > >>>>> On 3/10/2010 10:15 PM, Simone Busoli wrote:
>
> > > >>>>> 2010/3/10 Krzysztof Koźmic
<[email protected]
<mailto:[email protected]>>
>
> > > >>>>>> On 3/10/2010 9:59 PM, Simone Busoli wrote:
>
> > > >>>>>> inline
>
> > > >>>>>> 2010/3/10 Krzysztof Koźmic
<[email protected]
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>.
> > > >>>>>>> > To unsubscribe from this group, send
email to
> > > >>>>>>> >
[email protected]
<mailto:castle-project-users%[email protected]><castle-project-users%[email protected]
<mailto:castle-project-users%[email protected]>>
> > <castle-project-users%[email protected]
<mailto:castle-project-users%[email protected]><castle-project-users%[email protected]
<mailto: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]
<mailto:[email protected]>.
> > > >>>>>>> To unsubscribe from this group, send email to
> > > >>>>>>>
[email protected]
<mailto:castle-project-users%[email protected]><castle-project-users%[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
