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.
On Wed, Jul 2, 2008 at 8:42 PM, ashmind <ashm...@gmail.com> wrote:
> 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.
On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
> 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.
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.
On Wed, Jul 2, 2008 at 1:25 PM, 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.
> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
> > 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.
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.
On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: > 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.
> On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo > <hamm...@castlestronghold.com> wrote:
>> 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.
>> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
>> > 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.
> 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.
> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: > > 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.
> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> 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.
> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
> >> > 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.
On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: > That scenario sounds familiar and may be what I experienced.
> Did you get a circularity exception in this case too?
> On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo > <hamm...@castlestronghold.com> wrote:
>> 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.
>> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: >> > 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.
>> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo >> > <hamm...@castlestronghold.com> wrote:
>> >> 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.
>> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
>> >> > 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.
> On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: > > That scenario sounds familiar and may be what I experienced.
> > Did you get a circularity exception in this case too?
> > On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> 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.
> >> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> > wrote: > >> > 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.
> >> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo > >> > <hamm...@castlestronghold.com> wrote:
> >> >> 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.
> >> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
> >> >> > 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.
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?
On Wed, Jul 2, 2008 at 4:11 PM, Ayende Rahien <aye...@ayende.com> wrote: > No, we have a check for that
> On Wed, Jul 2, 2008 at 10:07 PM, Hamilton Verissimo > <hamm...@castlestronghold.com> wrote:
>> My guess is that you get a stack overflow...
>> On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: >> > That scenario sounds familiar and may be what I experienced.
>> > Did you get a circularity exception in this case too?
>> > On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo >> > <hamm...@castlestronghold.com> wrote:
>> >> 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.
>> >> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> >> >> wrote: >> >> > 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.
>> >> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo >> >> > <hamm...@castlestronghold.com> wrote:
>> >> >> 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.
>> >> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
>> >> >> > 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.
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
On 7/2/08, Hamilton Verissimo <hamm...@castlestronghold.com> wrote:
> 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?
> On Wed, Jul 2, 2008 at 4:11 PM, Ayende Rahien <aye...@ayende.com> wrote: > > No, we have a check for that
> > On Wed, Jul 2, 2008 at 10:07 PM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> My guess is that you get a stack overflow...
> >> On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> > wrote: > >> > That scenario sounds familiar and may be what I experienced.
> >> > Did you get a circularity exception in this case too?
> >> > On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo > >> > <hamm...@castlestronghold.com> wrote:
> >> >> 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.
> >> >> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> > >> >> wrote: > >> >> > 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.
> >> >> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo > >> >> > <hamm...@castlestronghold.com> wrote:
> >> >> >> 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.
> >> >> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> > wrote:
> >> >> >> > 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.
> 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?
> On Wed, Jul 2, 2008 at 4:11 PM, Ayende Rahien <aye...@ayende.com> wrote: > > No, we have a check for that
> > On Wed, Jul 2, 2008 at 10:07 PM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> My guess is that you get a stack overflow...
> >> On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> > wrote: > >> > That scenario sounds familiar and may be what I experienced.
> >> > Did you get a circularity exception in this case too?
> >> > On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo > >> > <hamm...@castlestronghold.com> wrote:
> >> >> 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.
> >> >> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> > >> >> wrote: > >> >> > 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.
> >> >> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo > >> >> > <hamm...@castlestronghold.com> wrote:
> >> >> >> 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.
> >> >> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> > wrote:
> >> >> >> > 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.
> 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.
On Wed, Jul 2, 2008 at 4:27 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: > 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
> On 7/2/08, Hamilton Verissimo <hamm...@castlestronghold.com> wrote:
>> 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?
>> On Wed, Jul 2, 2008 at 4:11 PM, Ayende Rahien <aye...@ayende.com> wrote: >> > No, we have a check for that
>> > On Wed, Jul 2, 2008 at 10:07 PM, Hamilton Verissimo >> > <hamm...@castlestronghold.com> wrote:
>> >> My guess is that you get a stack overflow...
>> >> On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> >> >> wrote: >> >> > That scenario sounds familiar and may be what I experienced.
>> >> > Did you get a circularity exception in this case too?
>> >> > On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo >> >> > <hamm...@castlestronghold.com> wrote:
>> >> >> 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.
>> >> >> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com> >> >> >> wrote: >> >> >> > 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.
>> >> >> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo >> >> >> > <hamm...@castlestronghold.com> wrote:
>> >> >> >> 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.
>> >> >> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> >> >> >> >> wrote:
>> >> >> >> > 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.
> On Wed, Jul 2, 2008 at 4:27 PM, Craig Neuwirt <cneuw...@gmail.com> wrote: > > 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
> > On 7/2/08, Hamilton Verissimo <hamm...@castlestronghold.com> wrote:
> >> 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?
> >> On Wed, Jul 2, 2008 at 4:11 PM, Ayende Rahien <aye...@ayende.com> > wrote: > >> > No, we have a check for that
> >> > On Wed, Jul 2, 2008 at 10:07 PM, Hamilton Verissimo > >> > <hamm...@castlestronghold.com> wrote:
> >> >> My guess is that you get a stack overflow...
> >> >> On Wed, Jul 2, 2008 at 3:51 PM, Craig Neuwirt <cneuw...@gmail.com> > >> >> wrote: > >> >> > That scenario sounds familiar and may be what I experienced.
> >> >> > Did you get a circularity exception in this case too?
> >> >> > On Wed, Jul 2, 2008 at 1:47 PM, Hamilton Verissimo > >> >> > <hamm...@castlestronghold.com> wrote:
> >> >> >> 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.
> >> >> >> On Wed, Jul 2, 2008 at 3:37 PM, Craig Neuwirt <cneuw...@gmail.com
> >> >> >> wrote: > >> >> >> > 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.
> >> >> >> > On Wed, Jul 2, 2008 at 1:25 PM, Hamilton Verissimo > >> >> >> > <hamm...@castlestronghold.com> wrote:
> >> >> >> >> 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.
> >> >> >> >> > 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.
<hamm...@castlestronghold.com> wrote:
> 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.
> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
> > 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.
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:
> > 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.
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.
On Wed, Jul 2, 2008 at 4:53 PM, ashmind <ashm...@gmail.com> wrote:
> I understand the concern, but what behavior might be broken?
> On Jul 2, 10:25 pm, "Hamilton Verissimo" > <hamm...@castlestronghold.com> wrote: >> 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.
>> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
>> > 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.
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.
On Wed, Jul 2, 2008 at 5:40 PM, Victor Kornov <wee...@gmail.com> wrote: > 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.
> On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > <hamm...@castlestronghold.com> wrote:
>> The worst scenarios are the ones I can't imagine. the microkernel >> extensility seems to be more in use than what I originally planned.
> 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.
> On Wed, Jul 2, 2008 at 5:40 PM, Victor Kornov <wee...@gmail.com> wrote: > > 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.
> > On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> The worst scenarios are the ones I can't imagine. the microkernel > >> extensility seems to be more in use than what I originally planned.
On Wed, Jul 2, 2008 at 6:36 PM, Ayende Rahien <aye...@ayende.com> wrote: > I would classify most of the people who use Windsor as advance users.
> On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > <hamm...@castlestronghold.com> wrote:
>> 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.
>> On Wed, Jul 2, 2008 at 5:40 PM, Victor Kornov <wee...@gmail.com> wrote: >> > 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.
>> > On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo >> > <hamm...@castlestronghold.com> wrote:
>> >> The worst scenarios are the ones I can't imagine. the microkernel >> >> extensility seems to be more in use than what I originally planned.
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.
On Thu, Jul 3, 2008 at 12:40 AM, Hamilton Verissimo <
> On Wed, Jul 2, 2008 at 6:36 PM, Ayende Rahien <aye...@ayende.com> wrote: > > I would classify most of the people who use Windsor as advance users.
> > On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> 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.
> >> On Wed, Jul 2, 2008 at 5:40 PM, Victor Kornov <wee...@gmail.com> wrote: > >> > 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.
> >> > On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > >> > <hamm...@castlestronghold.com> wrote:
> >> >> The worst scenarios are the ones I can't imagine. the microkernel > >> >> extensility seems to be more in use than what I originally planned.
> On Wed, Jul 2, 2008 at 6:36 PM, Ayende Rahien <aye...@ayende.com> wrote: > > I would classify most of the people who use Windsor as advance users.
> > On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > > <hamm...@castlestronghold.com> wrote:
> >> 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.
> >> On Wed, Jul 2, 2008 at 5:40 PM, Victor Kornov <wee...@gmail.com> wrote: > >> > 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.
> >> > On Thu, Jul 3, 2008 at 12:33 AM, Hamilton Verissimo > >> > <hamm...@castlestronghold.com> wrote:
> >> >> The worst scenarios are the ones I can't imagine. the microkernel > >> >> extensility seems to be more in use than what I originally planned.
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.
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.
<hamm...@castlestronghold.com> wrote:
> 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.
> On Wed, Jul 2, 2008 at 4:53 PM, ashmind <ashm...@gmail.com> wrote:
> > I understand the concern, but what behavior might be broken?
> > On Jul 2, 10:25 pm, "Hamilton Verissimo"
> > <hamm...@castlestronghold.com> wrote:
> >> 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.
> >> On Wed, Jul 2, 2008 at 2:42 PM, ashmind <ashm...@gmail.com> wrote:
> >> > 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.
