OK, I agree, using the builder approach looks compelling!
Though what about required settings? EG IW's builder must have
Directory, Analyzer. Would we pass these as up-front args to the
initial builder?
And shouldn't we still specify the version up-front so we can improve
defaults over time without breaking back-compat? (Else, how can
we change defaults?)
EG:
IndexWriter.builder(Version.29, dir, analyzer)
.setRAMBufferSizeMB(128)
.setUseCompoundFile(false)
...
.create()
?
Mike
On Fri, Oct 2, 2009 at 7:45 PM, Earwin Burrfoot <ear...@gmail.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
