Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of markrmiller@gmail.com
 designates 209.85.221.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=uQMQCCIeS33A2cjfk7oaxcHHbrtF8qv20s4W5RBu3uX7iaWhIMcRutMlj+P7lSdcOC
         cWg5nlplg8ntXLoAmqd0+dw2kZ6WFL1DWfq5Y/F+wO3LuNpk6KhyC6prh9scY9yz4mmR
         qPsI7SOIr2RESS5Hzan3jPQqmbdO0HOCZcEX4=
Message-ID: <4AC698E4.1050606@gmail.com>
Date: Fri, 02 Oct 2009 20:20:52 -0400
From: Mark Miller <markrmiller@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
References: <C43B8A7D81E54A9E81AAD411C141E4DB@VEGA>
	 <4AC684B7.2040505@gmail.com>
	 <59b3eb370910021625r3854c09dw3c280143aed87b1a@mail.gmail.com>
	 <A25B297E93DD444EB37D8EAC118E6B48@VEGA>
	 <59b3eb370910021645l154f1ee9p14586927b93fbbef@mail.gmail.com>
 <9ac0c6aa0910021715w6c67c26fwcd5b25d80d7b7217@mail.gmail.com>
In-Reply-To: <9ac0c6aa0910021715w6c67c26fwcd5b25d80d7b7217@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-U
Content-Transfer-Encoding: 8bit

Call me old fashioned, but I like how the non constructor params are set
now.

And for some reason I like a config object over a builder pattern for
the required constructor params.

Thats just me though.

Michael McCandless wrote:
> 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 <earwin@gmail.com> wrote:
>   
>> On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <uwe@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/������ ��������� (earwin@gmail.com)
>> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
>> ICQ: 104465785
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>   


-- 
- Mark

http://www.lucidimagination.com


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org