On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <u...@thetaphi.de> wrote: >> It is also probably a good idea to move various settings methods from >> IW to that builder and have IW immutable in regards to configuration. >> I'm speaking of the likes of setWriteLockTimeout, setRAMBufferSizeMB, >> setMergePolicy, setMergeScheduler, setSimilarity. >> >> IndexWriter.Builder iwb = IndexWriter.builder(). >> writeLockTimeout(0). >> RAMBufferSize(config.indexationBufferMB). >> maxBufferedDocs(...). >> similarity(...). >> analyzer(...); >> >> ... = iwb.build(dir1); >> ... = iwb.build(dir2); > > A happy user of google-collections API :-) These builders are really cool!
I feel myself caught in the act. There is still a couple of things bothering me. 1. Introducing a builder, we'll have a whole heap of deprecated constructors that will hang there for eternity. And then users will scream in frustration - This class has 14(!) constructors and all of them are deprecated! How on earth am I supposed to create this thing? 2. If someone creates IW with some reflectish javabeanish tools - he's busted. Not that I'm feeling compassionate for such a person. > 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. Besides (arguably) cleaner syntax, the lack of which is (arguably) a curse of many Java libraries, it also allows us to return a different concrete implementation of IW without breaking back-compat, and also to choose this concrete implementation based on settings provided. If we feel like doing it at some point. -- 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
