ArraySubDependencyResolver

[ashmind]

Hi All,

Could you please explain possible problems with having a built-in
ArraySubDependencyResolver in Castle?
While it is trivial to write one, I feel that it is one of the
essential DI features.

I can see following conceptual problems:
1. If you have a singleton consuming an service list, the actual
contents of service list in the singleton will depend on whether it
was resolved before all service implementations where registered.
2. If you have a Startable component, it will always get only single
element in service list if you register it before service
implementations.
3. If some service implementations can not be resolved, there is no
obvious answer on whether list-dependant component should fail its
Resolve or be resolved with available services only.

No one of these seems to be a feature showstopper.
Still, it would be very interesting for me to know if any other DI
framewrok had some interesting solutions to these issues.

Thanks in advance,

--
Andrey Shchekin
http://blog.ashmind.com

[Ayende Rahien]

+1 from me.

[Hamilton Verissimo]

I can add the resolver to the castle's code base. What I wont do is
adding it as a resolver by default. It might break existing behavior.

--
Cheers,
hamilton verissimo
ham...@castlestronghold.com
http://www.castlestronghold.com/

[Craig Neuwirt]

FYI, I tried to use that resolver once and noticed it created a circular dependency for a specific situation.  I can't remember off the top of my head, but if it gets checked in, i'll try to find my notes and add a test case for that and hopefully a resolution.

[Hamilton Verissimo]

A depends on IService[]
B, C and D implements IService
if one of those depend on A, you have a problem.

I wouldnt be worried about it though. One of the behaviors that I dislike is:

A asks for IService[]. If one of the IService implementation is in a
waiting state, it wont be included. Maybe I should throw an
exception... I dont know. Last time I had this I had to debug into to
see why it wasnt returning an implementation. It's the kind of silent
failure that I despise.

[Craig Neuwirt]

That scenario sounds familiar and may be what I experienced.

Did you get a circularity exception in this case too?

[Hamilton Verissimo]

My guess is that you get a stack overflow...

[Ayende Rahien]

No, we have a check for that

[Hamilton Verissimo]

from this http://hammett.castleproject.org/?p=257 I dont see the
creation context being propagated to the resolveall. how would the
circular problem be detected in this situation?

[Craig Neuwirt]

I was suprised when I saw a Ciculariry reported too, but I am certain that was the exception.   If I remember, the stack trace looked like overflow.

Either way, i'll try and reproduce and go from there.

 

thanks

 

[Ayende Rahien]

Hm, good point. It probably should.

[Victor Kornov]

This functionality could be packaged in a facility which will have a switch to throw or not in such cases.

[Hamilton Verissimo]

black magic then.

[Craig Neuwirt]

Eventually, you'll get old like me and tour memory will fade too.. :-)

[ashmind]

I understand the concern, but what behavior might be broken?

On Jul 2, 10:25 pm, "Hamilton Verissimo"

> hamm...@castlestronghold.comhttp://www.castlestronghold.com/

[ashmind]

I think this functionality is as essential as open generic types
support that is already built in.
So making it a facility is, possibly, making things too complex for a
basic-level feature.
I understand the compatibility concern, but I think it sometimes gives
too much edge to the new, unconcerned projects, and too much incentive
to build a new project instead of contributing to the existing one.

However, a switch would be definitely useful, so I am not sure.

On Jul 2, 11:32 pm, "Victor Kornov" <wee...@gmail.com> wrote:
> This functionality could be packaged in a facility which will have a switch
> to throw or not in such cases.
>
> On Wed, Jul 2, 2008 at 10:47 PM, Hamilton Verissimo <
>

[Hamilton Verissimo]

The worst scenarios are the ones I can't imagine. the microkernel
extensility seems to be more in use than what I originally planned.
People usually rely on ISubDependencyResolver and converters to
customize behavior. Introducing this in a build might impact/break
their extensions.. It's like the same reason MS refuses to fix things
that are unarguably broken..

If we held a vote on it, though, and it's approved, I'd be more
comfortable adding it in.

--

[Victor Kornov]

You give people something and they immediately start to abuse it. And do all sorts of things unimaginable.

Standard facility would be OK for me, that way it will be optional.

[Hamilton Verissimo]

I wont go that far, I just originally thought that only advanced users
would go and extend the container, and it seems that almost everyone
does. It's cool.

It does impose a challenge whenever we want to make a change.

--

[Ayende Rahien]

I would classify most of the people who use Windsor as advance users.

[Hamilton Verissimo]

Why?

[Ayende Rahien]

Because it is still seen in such a fashion, at least in the .Net circles.
It is gaining acceptance, but it still a high end solution.
I don't think it should be, but that is a different matter.

[William C. Pierce]

There is no visual designer or drag-n-drop configuration tool for Windsor.  That automatically makes anyone who uses it an advanced user.

[Hamilton Verissimo]

That's just your perception. Based on the questions on this list and
forums I'm sure we have all levels of users using it.

Not sure about liking it, though :-)

On Wed, Jul 2, 2008 at 6:45 PM, Ayende Rahien <aye...@ayende.com> wrote:
> Because it is still seen in such a fashion, at least in the .Net circles.
> It is gaining acceptance, but it still a high end solution.
> I don't think it should be, but that is a different matter.

--

[ashmind]

I think anyone who ever written a SubDependencyResolver is a person
who can fix it if something has gone wrong.
It is an advanced topic.

The MS position is understandable, but they have a lot more users and
skill differentiation is more deep.
And their position basically means API pollution and confusion for the
new users -- DateTime or DateTimeOffset, what to choose.
They can not do otherwise, but lesser frameworks can.

On Jul 3, 12:33 am, "Hamilton Verissimo"

> hamm...@castlestronghold.comhttp://www.castlestronghold.com/

[Hamilton Verissimo]

On Thu, Jul 3, 2008 at 2:51 AM, ashmind <ash...@gmail.com> wrote:
> I think anyone who ever written a SubDependencyResolver is a person
> who can fix it if something has gone wrong.

This is not the best attitude towards users.

[Andrey Shchekin]

>> I think anyone who ever written a SubDependencyResolver is a person
>> who can fix it if something has gone wrong.
> This is not the best attitude towards users.

I, personally, do not mind reasonable and minor breaking changes in
frameworks I use. But you are right, sorry for overgeneralizing.

[ashmind]

My concerns with defaults are not that major.
If the Resolver is added but not registered I am will be happy anyway.

On Jul 2, 10:25 pm, "Hamilton Verissimo"
<hamm...@castlestronghold.com> wrote:

> hamm...@castlestronghold.comhttp://www.castlestronghold.com/