Wouldn't it make it identical to the 1st example?
That's what it is doing.
On 3/12/2010 11:23 PM, Simone Busoli wrote:
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].
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].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
