I think the last piece that is needed is to ask on java-user what
others think. In order to do that, I think it needs to be boiled down
to a couple paragraphs.
-Grant
On May 29, 2009, at 11:22 PM, Shai Erera wrote:
So ... I've this happen a lot of times (especially in my thesis
work) - someone raises a controversial topic, or one that touches
the nervous of the system, there's a flurry of activity and then it
dies unexpectedly, even though it feels to everyone that there's "an
extra mile" that should be taken in order to bring it to completion.
And that's what I've seen in this thread. A lot has been said - lots
of comments, ideas, opinions. Lots of ranting and complaining. Then
it died ... Thank you Grant for that last "beep", I hope that was an
intention to resurrect it.
So I ask - how come that we don't have a decision? Is it because
we're "afraid" to make a decision? (that last sentence is supposed
to "tease" the community, not to pass judgement)
I'm asking because it seems like everybody pretty much agrees on
most of the suggestions, so why not decide "let's do X, Y and Z" and
change the back-compat page starting from 2.9? If people don't
remember the decisions, I don't mind reiterating them.
(I also ask because I'd like to take the improvements from
LUCENE-1614 to TermDocs/Positions, PhrasePositions, Spans. All
except PhrasePositions are public interfaces and so it matters if I
need to go through creating abstract classes, with new names, or I
can change those interfaces, asking those that implemented their own
TermDocs to modify the code).
Shai
On Wed, May 27, 2009 at 10:36 PM, Grant Ingersoll
<gsing...@apache.org> wrote:
So, here's a real, concrete example of the need for case by case
back compat. See https://issues.apache.org/jira/browse/LUCENE-1662
It's completely stupid that ExtendedFieldCache even exists. It is
a dumb workaround for a made up problem that has nothing to do with
real coders living in the modern age of development where IDE's make
refactoring these types of things very cheap. Namely, the notion
that interfaces must never change lest every 6-9 months some minute
number of users (I'd venture it's less than 1% of users) out there,
who by any account are completely capable of implementing hard core
Lucene internals (like extending FieldCache), yet are seemingly
incapable of reading a CHANGES file with a huge disclaimer in it,
have to recompile (GASP!) their code and put in a dummy
implementation of some new interface method. Yet, here we are with
Yonik fixing very real problems that are a direct result of coding
around back compat. (along with a mistake; it took a long time for
this issue to even be discovered) that very much effect the
usability of Lucene and the day to day experience of a good number
of users.
In other words, the real fix for L-1662 is for ExtFieldCache to be
folded into FieldCache and for the file to be removed, never to be
heard from again.
The same can be said for the whole Fieldable issue, but that's a
different day.
Ranting,
Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
using Solr/Lucene:
http://www.lucidimagination.com/search
