java-dev@lucene.apache.org
[Top] [All Lists]

Re: Proposal about Version API "relaxation"

Subject: Re: Proposal about Version API "relaxation"
From: Robert Muir
Date: Wed, 14 Apr 2010 09:13:27 -0400
Its not sidetracked at all. there seem to be more compelling alternatives to achieve the same thing, so we should consider alternative solutions, too.

On Wed, Apr 14, 2010 at 8:54 AM, Earwin Burrfoot <earwin@xxxxxxxxx> 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 <gsingers@xxxxxxxxxx> wrote:
>
> On Apr 14, 2010, at 12:49 AM, Robert Muir wrote:
>
>>
>> On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey <marvin@xxxxxxxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxx
> For additional commands, e-mail: java-dev-help@xxxxxxxxxxxxxxxxx
>
>



--
Kirill Zakharenko/ÐÐÑÐÐÐ ÐÐÑÐÑÐÐÐÐ (earwin@xxxxxxxxx)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: java-dev-help@xxxxxxxxxxxxxxxxx




--
Robert Muir
rcmuir@xxxxxxxxx
<Prev in Thread] Current Thread [Next in Thread>