On 04/14/2010 09:13 AM, Robert Muir wrote:
Its not sidetracked at all. there seem to be more compelling
alternatives to achieve the same thing, so we should consider
alternative solutions, too.
Maybe have the index store the version(s) and use that when constructing
a reader or writer?
Given enough minor releases, it is likely that different analyzers would
use different versions. So each feature would need to be represented.
On Wed, Apr 14, 2010 at 8:54 AM, Earwin Burrfoot <ear...@gmail.com
<mailto:ear...@gmail.com>> wrote:
The thread somehow got sidetracked. So, let's get this carriage back
on its rails?
Let me remind - we have an API on hands that is mandatory and tends to
be cumbersome.
Proposed solution does indeed have ultrascary word "static" in it. But
if you brace yourself and look closer - the use of said static is
opt-in and heavily guarded.
So even a long-standing hater of everything static like me is tempted.
On Wed, Apr 14, 2010 at 16:30, Grant Ingersoll
<gsing...@apache.org <mailto:gsing...@apache.org>> wrote:
>
> On Apr 14, 2010, at 12:49 AM, Robert Muir wrote:
>
>>
>> On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey
<mar...@rectangular.com <mailto:mar...@rectangular.com>> wrote:
>> New class names would work, too.
>>
>> I only mention that for the sake of completeness, though --
it's not a
>> suggestion.
>>
>> Right, to me this is just as bad.
>> In my eyes, the Version thing really shows the problem with the
analysis stuff:
>> * Used by QueryParsers, etc at search and index time, with no
real clean way to do back-compat
>> * Concepts like Version and class-naming push some of the
burden to the user: users decide the back-compat level, but it
still leaves devs with back-compat management hassle.
>>
>> The idea of having a real versioned-module is the same as
Version and class-naming, except it both pushes the burden to the
user in a more natural way (people are used to versioned jar files
and things like that... not Version constants), and it relieves
devs of the back compat
>>
>> In all honesty with the current scheme, release schedules of
Lucene, and Lucene's policy, the analysis stuff will soon deadlock
into being nearly unmaintainable, and to many users, the API is
already unconsumable: its difficult to write reusable analyzers
due to historical relics in the API, methods are named
inappropriately, e.g. Tokenizer.reset(Reader) and
TokenStream.reset(), they don't understand Version, and probably a
few other things I am forgetting that are basically impossible to
fix right now with the current state of affairs.
>
>
> The thing I keep going back to is that somehow Lucene has
managed for years (and I mean lots of years) w/o stuff like
Version and all this massive back compatibility checking. I'm
still undecided as to whether that is a good thing or not. I also
am not sure whether it in the past we just missed/ignored more
back compatibility issues or whether now we are creating more back
compat. issues due to more rapid change. I agree, though, that
all of this stuff is making it harder and harder to develop (and I
don't mean for us committers, I mean for end consumers.)
>
> I also agree about Robert's point about the incorrectness of
naming something 3.0 versus 3.1 when 3.1 is the thing that has all
the new features and is really the "major" release.
>
> -Grant
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
>
>
--
Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com
<mailto:ear...@gmail.com>)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
For additional commands, e-mail: java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
--
Robert Muir
rcm...@gmail.com <mailto:rcm...@gmail.com>
