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.
