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
