On Wed, Apr 15, 2009 at 00:55, Mark Miller <markrmil...@gmail.com> wrote: > Earwin Burrfoot wrote: >> >> On Wed, Apr 15, 2009 at 00:15, Mark Miller <markrmil...@gmail.com> wrote: >> >>> >>> Mark Miller wrote: >>> >>>> >>>> Earwin Burrfoot wrote: >>>> >>>>> >>>>> Mark Miller wrote: >>>>> >>>>> >>>>>> >>>>>> The distinction I am making with core is that we will have to call >>>>>> known >>>>>> methods on those >>>>>> core 'modules' that are not very generic? Doesn't that keep it from >>>>>> playing >>>>>> nice with the very generic 'attach this to this segment'? >>>>>> >>>>>> >>>>> >>>>> Genericity spans binding, notifications and retrieval of a component >>>>> from a reader. >>>>> >>>>> For binding and notifications you can do whatever you want inside your >>>>> component, because you're provided with the full public IndexReader >>>>> interface. >>>>> When you retrieve a component, you get your very own interface with >>>>> all your needed and totally nongeneric methods. >>>>> >>>>> ObscureComponent c = reader.plugin(ObscureComponent.class); >>>>> c.performSomeObscureNonGenericLogic(); >>>>> >>>>> This very code can be located both in userland, dealing with custom >>>>> components and in coreland, dealing with well-known Lucene core >>>>> components. >>>>> >>>>> >>>>> >>>> >>>> Thats sounding interesting. From what you and Mike are saying, its a >>>> dependency injection framework basically then? Impls are plugged in from >>>> a >>>> configuration class? Except you can plug in your own random stuff thats >>>> not >>>> used internally, so its also kind of an Impl cache? >>>> >>>> >>>> So IndexReader Plugins would be: per Reader impl configuration and >>>> caching >>>> - with call backs too though - I guess you could add other callbacks and >>>> get >>>> involved in some more interesting stuff as well, if you wanted? >>>> >>>> It keeps growing on me anyway. >>>> >>>> >>> >>> Or its per Reader dependency injection with singleton support only and >>> support for lifecycle callbacks? >>> >> >> I'm not really going to inject dependencies, so it's more like >> "service locator" than "dependency injection". >> > > I don't see the distinction really - unless your saying its that a service > locator may be happy ignoring a missing implementation. From the core > modules perspective, it seems more like straight dependency injection to me. It's a matter of who has control. service locator = components ask for their dependencies dependency injection = components are stuffed full with their dependencies For that distinction to become more visible we need to introduce chained dependencies, alternate dependencies, missing/optional dependencies, etc. Not going to do this :)
>> So far we discussed per-reader component instances (I can't force >> myself to call them singletons) > Right - I don't mean to just call them singletons, it was just part of the > analogy. In dependency injection you generally have the option of getting > fresh instances or a singleton. In that way, I was comparing it to a per > reader dependency injection framework set to singleton rather than new > instance. Its not *really* a singleton, because its per reader. Then, in your terminology, they are singletons, yes. >> , with lifecycle callbacks. These >> instances also serve as a factory for instances attached to >> subreaders. >> > I don't quite understand that. Do you mean, back to my confusing analogy, > that we will have both per reader singletons, as well as the option to ask > for new instances then? We'll have per-reader singletons for toplevel readers which will be asked for instances of themselves for newly created subreaders. I'm not myself sure of exact design yet. > LuceneGuice :) (Thats completely a throwaway, so don't draw any conclusions > from it :)) I'm absolutely not going to build some uberframework. Something simple. A hashmap. And a pair of helper methods. Maybe one class. And a bunch of interfaces. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
