> 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.
This is a really cool example of this builder pattern: http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/ common/collect/MapMaker.html > > -----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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
