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