The only thing that I can think of is something like:
var sender = container.Resolve<INotificationSender>(new
ProvideHostArgument("somehost"));
So we pass some ISubDependencyResolver() that apply only for this
resolution.
On Sat, Dec 27, 2008 at 7:07 AM, hammett <[email protected]> wrote:
>
> > var sender = container.Resolve<INotificationSender>(new { Host =
> "somehost"
> > });
>
> This is very cryptic. I'd argue that it only makes sense to whomever
> implemented the feature. If there's a way to pass in the call the
> target component that you want to override the parameters, I'd be more
> comfortable with this feature.
>
> On Fri, Dec 26, 2008 at 9:02 PM, Ayende Rahien <[email protected]> wrote:
> > It is actually very useful to be able to give a dependency for anything
> on
> > the chain. I agree that matching by name is... not ideal, but I don't see
> > any other choice.
> > Imagine:
> >
> > var sender = container.Resolve<INotificationSender>(new { Host =
> "somehost"
> > });
> >
> > Where INotificationSender depends on IEmailSender, which depends on Host.
> >
> > On Sat, Dec 27, 2008 at 3:05 AM, hammett <[email protected]> wrote:
> >>
> >> I wasnt sure what was the additionalArgs behavior when going down in
> >> the dependency chain, so I added a test, which failed but that's
> >> another story.
> >>
> >> Seems that the current behavior is to propagate the additionalArgs
> >> which makes me a bit uncomfortable. Think about it: every parameter
> >> set on that dictionary will be matched by name, without a scope. This
> >> has a great potential of name clashing leading to unexpected behavior.
> >> I have commented the code that propagates it (CreationContext
> >> constructor that takes a parent context) but even that isn't good
> >> enough.
> >>
> >> As an user I'd expect a very well defined and predictable behavior. So
> >> for a usage like
> >>
> >> var sender = container.Resolve<IEmailSender, new { Host = "somehost"
> }>();
> >>
> >> I would expect that the host of the IEmailSender will be the only one
> >> affected, not any dependency that the email sender happens to have..
> >> does that make sense?
> >>
> >> Currently I believe this is the behavior I left but more tests or
> >> thinking are appreciated. The construction graph is inverted if
> >> dependencies are set through constructors but I'd hope that the root
> >> CreationContext will be tied to the root component/default handler.
> >>
> >>
> >> Thoughts?
> >>
> >> --
> >> Cheers,
> >> hammett
> >> http://hammett.castleproject.org/
> >>
> >>
> >
> >
> > >
> >
>
>
>
> --
> Cheers,
> hammett
> http://hammett.castleproject.org/
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" 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-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
