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 <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> > 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> 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 > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > > > -- > Kirill Zakharenko/Кирилл Захаренко (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 > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Robert Muir rcm...@gmail.com
