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 buschmic@gmail.com designates
 72.14.220.156 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:content-type:content-transfer-encoding;
        b=C8fev6jAnhfgI7w0kgXbqZJNb5Wp+qs7VDZCBgIJskypeDj7zbNSTfqjMDOoBsPlCt
         4P18U/wfmzG9EKqUX8sdfwQk5Nz4MXwgBhwHnyozBv04D5Idjio3Y+7NDsxseFSMaavG
         s4diakvofsNT4IhWIgrJC5GNGqd6eBPS72W6c=
Message-ID: <4AC7E7D0.8060408@gmail.com>
Date: Sun, 04 Oct 2009 02:09:52 +0200
From: Michael Busch <buschmic@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
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>
	 <4AC698E4.1050606@gmail.com>
 <59b3eb370910021918h797027e8qf30761dd22e8f6e5@mail.gmail.com>
In-Reply-To: <59b3eb370910021918h797027e8qf30761dd22e8f6e5@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 10/3/09 4:18 AM, Earwin Burrfoot wrote:
> Builder pattern allows you to switch concrete implementations as you
> please, taking parameters into account or not.
> Besides that there's no real difference. I prefer builder, but that's just me :)
>
>    

Why can't you do that with a factory that takes a config object as 
parameter? Seems very similar to me... the only difference is syntax, 
isn't it?
And if you have setter methods on the config object or methods that 
return "this" that you can concatenate is just personal preference, 
right? Personally I prefer the setter methods for our usecase, simply 
because there are so many config options. Maybe you don't want to set 
them all in the same places in your app code? E.g. in our app we have a 
method like applyIWConfig(IndexWriter) that, as the name says, applies 
all settings we have in a customizable config file. However, some IW 
settings are not customizable, and applied somewhere else in our code. I 
think with the concatenation pattern this would look less intuitive than 
with good old setter methods. You'd have to change 
applyIWConfig(IndexWriter.Builder) to return IW.Builder and do the 
concatenation both in the method and in the caller.

But, like Mark said, maybe this is just my personal preference and for 
others not compelling arguments. Or maybe I'm missing some other 
advantage of the builder pattern? I haven't used/implemented it myself 
very much yet...

  Michael

>> 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
>>
>>
>>      
>
>
>    


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