lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <ear...@gmail.com>
Subject Re: IndexReader plugins
Date Tue, 14 Apr 2009 21:21:53 GMT
On Wed, Apr 15, 2009 at 00:55, Mark Miller <markrmiller@gmail.com> wrote:
> Earwin Burrfoot wrote:
>>
>> On Wed, Apr 15, 2009 at 00:15, Mark Miller <markrmiller@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/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message