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
