pull request: https://github.com/castleproject/Castle.Windsor/pull/5 ioc ticket: http://issues.castleproject.org/issue/IOC-268
On Jan 21, 11:41 am, Krzysztof Koźmic <[email protected]> wrote: > yeap. > > pull request and open a ticket in the issue tracker (unless there's one > already.) > > On 21/01/2011 8:40 PM, Mogens Heller Grabe wrote: > > > > > > > > > So, at this point do I send a pull request or how does that stuff > > work? > > > As I have already demonstrated, I am a Git n00b, so please guide me :) > > > On Jan 21, 11:24 am, Krzysztof Koźmic<[email protected]> > > wrote: > >> Mogens, > > >> I had a look and it looks good :) > > >> I see the behavior you sticked to is to ignore selected handlers if they > >> can't be resolved, and I agree with that. > > >> One thing I'm not exactly convinced I like (the root cause is not > >> related to your proposed solution) is we're introducing another method > >> on the IKnernel to add filters to naming subsystem. > > >> On the back of my head I still keep the > >> suggestion:http://castle.uservoice.com/forums/38955-windsor-v3/suggestions/45551... > > >> I would llike to be able to shove the selector into the conrainer, much > >> like ILazyComponentLoaders > >> That's a much (much) bigger problem to tackle so for v. Wawel we'll > >> probably add the method as you suggested, unless someone comes up with a > >> good implementation of self-bootstrapping container. > > >> all in all - good job, thanks. > > >> Krzysztof > > >> On 21/01/2011 5:48 PM, Mogens Heller Grabe wrote: > > >>> I came up with IHandlerFilter because I thought something like: > >>> "What is the difference between IHandlerSelector and this new thing?" > >>> "Well, IHandlerSelector picks (or doesn't) a single handler out of the > >>> available handlers, whereas this new thing filters the available > >>> handlers." > >>> "All right! 'IHandlerFilter' it is then!" > >>> </internaldialogue> > >>> I'm definitely open to better names :) > >>> On Jan 20, 11:52 pm, Krzysztof Koźmic<[email protected]> > >>> wrote: > >>>> One question we should answer is - what if one of the selected handlers > >>>> is unresolvable? > >>>> Should we throw or should we skip it. > >>>> Currently when we call ResolveAll we TryResolve handlers and just skip > >>>> them if we can't. > >>>> In here though, the IHandlerFilter explicitly picks those it wants, so > >>>> one could argue that we should throw if any of them is not resolvable. > >>>> I'd stick to the current behavior (ignore) but I'm open for compelling > >>>> arguments for the other option. > >>>> Also I'd like IHandlerSelector and IHandlerFilter to have more unified > >>>> name. They do pretty much the same thing, so it would be good to have > >>>> their names suggest that. > >>>> Krzysztof > >>>> On 20/01/2011 9:17 PM, Mogens Heller Grabe wrote: > >>>>> Hi Group! > >>>>> I have made an implementation of a "multi handler selector", or > >>>>> "handler filter" as I have called it. > >>>>> I would be extremely happy if someone would review the code and tell > >>>>> me what I have messed up, what I didn't consider because I'm a n00b, > >>>>> etc. :) > >>>>> It's analoguous to IHandlerSelector, except that IHandlerFilter does > >>>>> not take a key as argument, and it must return an array of handlers. > >>>>> The logic is implemented in DefaultNamingSubSystem. > >>>>> The commit is > >>>>> here:https://github.com/mookid8000/Castle.Windsor/commit/683e9a227dd359198... > >>>>> Thanks in advance! -- 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.
