On Fri, May 22, 2009 at 12:37 PM, Marvin Humphrey
<mar...@rectangular.com> wrote:

> I still like per-class settings classes.  For instance, an IndexWriterSettings
> class which allows you to hide away all the tweaky stuff that's cluttering up
> the IndexWriter API.
>
>   IndexWriterSettings settings = new IndexWriterSettings("3.1");
>   IndexWriter writer = new IndexWriter("path/to/index", analyzer, settings);

Unfortunately, switching to a separate Settings class is a much bigger
project, than the other proposals.

With actsAsVersion per-class, we could add that arg only to the
classes that needed it.  But with Settings, I assume we'd have to go
whole hog and pull out all of IWs settings into this separate class.

There are tricky questions with Settings too.  EG when are you allowed
to change a setting?  Some settings in IW must be known in the ctor
(autoCommit) and can't be changed later.  Others need to propogate on
change, so we'd need some mechanism for IW to be notified when a
specific setting changed.

I agree Settings also buy us neat possibilities, eg we could make
different Settings for "good search relevance" vs "high search
throughpug" vs "high indexing throughput", etc., but this is way
beyond just making sure new users see the best of Lucene.  Using
settings for back compat seems like overkill.

I also see Settings as something of a distraction.  Ie we have lots of
neat features, ideas to work on in Lucene that improve its
functionality, where I'd rather see our effort spent.

> I also think that the argument should be optional rather than mandatory, and
> that defaults should remain stable between major releases.  In other words, to
> take advantage of improved defaults, you need to ask for them -- but new users
> don't have to think about such things during the initial learning phase.

I feel the opposite: I'd like new users to see improvements by
default, and users that require strict back-compate to ask for that.

Mike

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

Reply via email to