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.
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.
, 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?
LuceneGuice :) (Thats completely a throwaway, so don't draw any
conclusions from it :))
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
