[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lucene-dev
Subject:    RE: Interfaces
From:       "Robert Engels" <rengels () ix ! netcom ! com>
Date:       2005-03-17 15:58:24
Message-ID: LMENLAOACIBLMOIILNNNMEOGEMAA.rengels () ix ! netcom ! com
[Download RAW message or body]

I only speak from current project experience, where we've developed a
"search server" utilizing lucene , utilizing custom indexing formats in
order to support high-speed incremental indexing. It was necessary to extend
IndexReader in order to have the rest of the searching framework work
properly, even though I use NO METHODS in the base class. Seems silly.

-----Original Message-----
From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
Sent: Thursday, March 17, 2005 5:31 AM
To: java-dev@lucene.apache.org
Subject: Re: Interfaces


I think, though I'm not speaking for anyone here but myself, that the
Lucene team is open to API improvements that _do not adversely affect
performance_ and that have _a real benefit_.

While I'm as IoC and design pattern savvy as the next developer, I'm
also highly pragmatic.  I've not been convinced by any of the examples
thus far.  If a unit test needs to detect if a document has been added,
you can check the size of the index before and after for example,
rather than doing some mock trickery to hook the addDocument call.  Or
you could use AspectJ to do this if you really wanted to get fancy.
The unit test example shown is really a unit test appropriate to Lucene
itself, and not to a project using Lucene, it seems.  Pragmatically,
have you ever had addDocument fail?  If not, then what peace of mind
are you getting from such a test?

Ultimately, though, the decision to refactor the codebase to use
interfaces more pervasively lies with Doug.

	Erik

On Mar 17, 2005, at 2:40 AM, Konstantin Priblouda wrote:

>
> --- Robert Engels <rengels@ix.netcom.com> wrote:
>
>> I've been pushing for making IndexReader and
>> IndexWriter interfaces for a
>> long time (and changing lucene core to use them),
>> but there seems a
>> reluctance to do so (although I am not sure why).
>> The current factory
>> methods could be easily moved to a IndexReaderWriter
>> factory class. Probably
>> a top-level interface IndexReaderWriter with methods
>> like isWritable() for
>> "read only" indices, and methods getReader(),
>> getWriter().
>
>
> Hi guys,
> what about  making lucene a bit more IoC Friendly?
> ( I speak of providing objects that can be created wia
> constructor, and not by factory )
>
> I'm tired of writing adapter classes...
>
> regards,
>
> ----[ Konstantin Pribluda ( ko5tik ) ]----------------
> Plugins for xdoclet-2 are released. check it out at:
> http://www.sourceforge.net/projects/xdoclet-plugins/
> ----[ http://www.pribluda.de ]------------------------
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org


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


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

[prev in list] [next in list] [prev in thread] [next in thread]