I like Earwin's version more. A builder is very flexible, because you can concat all your properties (like StringBuilder works with its append method returning itself) and create the instance at the end.
----- 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 1:37 AM > To: java-dev@lucene.apache.org > Subject: Re: Lucene 2.9 and deprecated IR.open() methods > > I think this would make sense... though, it'd be a shame if the > "simple case" becomes overbearing. Maybe we can keep good defaults, > but use Version to allow us to change them. So eg: > > new IndexWriter(new IndexWriter.Config(dir, analyzer, > Version.LUCENE_29)); > > would be the "simple" case. > > Mike > > On Fri, Oct 2, 2009 at 6:54 PM, Michael Busch <busch...@gmail.com> wrote: > > I was thinking lately about the large quantity of IndexWriter > constructors > > and IndexReader open methods. I'm not sure if this has been proposed > before, > > but what if we introduced new objects, e.g. IndexWriterConfig and > > IndexReaderConfig. They would contain getter/setter methods for all the > > different parameters the various constructors and open methods currently > > have. Then there would only be one IW constructor taking an > > IndexWriterConfig object as parameter and one open method in IR > likewise. > > Then going forward we won't have to add/deprecate more ctors or open > > methods, we can then easily extend or deprecate getters/setters in the > > *Config classes. > > > > Michael > > > > On 10/3/09 12:41 AM, Uwe Schindler wrote: > >> > >> When looking for press articles about the release of Lucene 2.9, I > found > >> the > >> following one from Bernd Fondermann > >> @ http://it-republik.de/jaxenter/artikel/Apache-Lucene-2.9-2594.html > >> > >> Translation with Google Translate: > >> > >> ----------------------------------------------------------------------- > ----- > >> Deprecated > >> > >> An index reader is created via the static open () factory method, of > which > >> there were 2.4 in all nine. Five of them are now deprecated. In 2.9 > there > >> are now a total of 14 open-overloaded variants, with eight of them but > >> they > >> are deprecated. This means that there are even some additions that have > >> been > >> directly identified with introduction as deprecated - confusing. > >> > >> The constructor-Deprecation orgy goes for the standard Analyzer, one of > >> the > >> key classes during indexing and querying further. This class has now > >> no-less > >> constructor arguments over what might, perhaps, some downstream > libraries > >> bring to stumble to instantiate their analyzer on a property, which > >> contains > >> the class name dynamically. Instead, an object version must be given to > >> set > >> for compatibility with 2.4 or 2.9. Both the VERSION_24 as well as the > >> VERSION_29 parameters are deprecated but themselves - very confusing! > >> VERSION_CURRENT is the only safe investment in the future, a value > which > >> we > >> certainly also as assignment in a zero-argument constructor would have > >> trusted. > >> > >> To write an index we need an index writer instance. Again, the majority > of > >> the 19 possible constructors are about to be put to retire to. > >> > >> ----------------------------------------------------------------------- > ----- > >> > >> What was going wrong with the open() hell in IR? Very strange, I should > >> have > >> looked better. > >> > >> By the way: How to proceed with deprecation removal? Case-by-case (e.g. > >> start with TS API, then these open() calls, then FSDirectory - to list > the > >> ones I was involved) or some hyper-patch? > >> > >> By the way, here is my talk @ Hadoop GetTogether in Berlin: > >> > >> > >> http://blog.isabel-drost.de/index.php/archives/category/events/apache- > hadoop > >> -get-together-berlin > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> H.-H.-Meier-Allee 63, D-28213 Bremen > >> http://www.thetaphi.de > >> eMail: u...@thetaphi.de > >> > >> > >> > >> --------------------------------------------------------------------- > >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
