This is almost the same but with a fluent touch:

var sender = container.Resolve<INotificationSender>(
    Dependencies.For<IEmailSender>(new { Host = "somehost" })
);

On Sat, Dec 27, 2008 at 2:15 AM, Jonathon Rossi <[email protected]> wrote:

> Do you mean something like this:
>
> var sender = container.Resolve<INotificationSender>(
>     new Dependency<IEmailSender>(new { Host = "somehost" })
> );
>
>
> On Sat, Dec 27, 2008 at 3:07 PM, 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/
>>
>>
>>
>
>
> --
> Jonathon Rossi
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to