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

Reply via email to