Well, let's first get 3.0 out the door ;) Then we can salivate over all sorts of juicy changes for 3.1...
These particular changes (switching syntax from multi-ctors to config or to builder, disallowing config changes after creation, switching to "concrete impl is hidden") may merit an exception to our back-compat policy. Obviously users are bothered by the horror of how many ctors you are confronted with for IW and IR. Mike On Sat, Oct 3, 2009 at 5:46 AM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > The problem is, we have to leave some of the not-yet-deprecated ctors/opens > available for a while (not until 4.0 with our ne policy), but a user > removing all deprecated stuff from his 2.9 release should be able to switch > to 3.0 without changing any code (can even plug the jars in). We also have > to keep the getters/setter avail. If we wanted to change this, 2.9 was the > best option :-( > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > >> -----Original Message----- >> From: Michael McCandless [mailto:luc...@mikemccandless.com] >> Sent: Saturday, October 03, 2009 11:35 AM >> To: java-dev@lucene.apache.org >> Subject: Re: Lucene 2.9 and deprecated IR.open() methods >> >> On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot <ear...@gmail.com> wrote: >> >> Call me old fashioned, but I like how the non constructor params are >> set >> >> now. >> > And what happens when you index some docs, change these params, index >> > more docs, change params, commit? Let's throw in some threads? >> > You either end up writing really hairy state control code, or just >> > leave it broken, with "Don't change parameters after you start pumping >> > docs through it!" plea covering your back somewhere in JavaDocs. >> > If nothing else, having stuff 'final' keeps JIT really happy. >> >> This is a good point: are you allowed to change config settings after >> creating your IndexWriter/Reader? >> >> Today it's ad hoc. >> >> EG IW does not allow you to swap out your deletion policy, because >> it'd be a nightmare to implement. You also can't swap the analyzer. >> But it does let you change your RAM buffer size, CFS or not, merge >> factor, etc. We can remove that flexibility (I'm not sure it's >> compelling), so we can make things final. You can't change read-only >> after opening your IndexReader. I think it'd make sense to move away >> from changing settings after construction... >> >> But: the "do we disallow changing config settings after construction?" >> question is really orthogonal to the "what syntax do we use for >> construction?" (builder vs config vs zillions-of-ctors). >> >> Mike >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
