On Wed, 20 May 2009, Michael McCandless wrote:
On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley
<yo...@lucidimagination.com> wrote:
On Wed, May 20, 2009 at 11:46 AM, Mark Miller <markrmil...@gmail.com> wrote:
Marvin Humphrey wrote:
Yeesh, that's evil. :(
It will be sweet, sweet justice if one of your own projects gets infected
by
the kind of action-at-a-distance bug you're so blithely unconcerned about
Heh. Thats a bit over the top. It is evil stuff, but its much less evil in
this very contained instance than the general case. Much less.
But still a bit evil with the potential to grow. I'm not anymore of a fan of
passing a config to each class though. But I guess from a design point
of view, it does feel a little less evil.
Agree.
But passing settings around doesn't solve the problem. Example: New
settings may be chosen by an application for an IndexSearcher that's
incompatible with a custom older Query/Weight/Scorer. There's really
no getting around that problem. I think the static helps solve
drop-in compat for a complete working application. Good components
should only be checking the static, not setting it.
Also, this static setting simply tells Lucene how to default settings.
A component/app can still be explicit when creating classes. EG when
opening an IndexReader, if one always passes in the readOnly arg then
the static "actsAsVersion" would not be used.
I've been watching this thread with interest with my opinion swaying back
and forth.
This last comment, though, pushes me to favor the settings class idea
because that idea came with the promise of eliminating the combinatorial
explosion of contructor and method overloads.
In addition, I very much like the idea of having one place list all the
coherent configuration choices one can make. No, CHANGES.txt is not it.
While it's interesting reading, it reads like a blog. It doesn't tie
sensible settings together. It only gives a differential and chronological
view of changes.
Having version-specific settings classes is a really neat place to list all
possible settings in one place with sensible and coherent values for a
version. The same idea could be used for other things than version by the
way. It could help in picking one side of a configuration trade off over
another.
For example:
- a settings for favoring speed of updates over speed of queries if that
makes sense
- a settings for favoring index size over indexing speed
... and so on.
I don't see why this has to be limited just to Lucene version backwards
compatibility. Oh, and about that: I think we've reached the breaking point
about backwards compatibility support a while ago. I recently hit a bug in
my code where a commit() call was missing. Before 2.4, flushing the index
committed it. Starting with 2.4, this is no longer the case. Yes, this is
documented and that helped me fix the bug really quickly but backwards
compatible it is not. My point here is that we've promised too much
backwards compatibility for too long and it's been getting too hard to
deliver that promise now.
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
