lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Sun, 04 Oct 2009 00:20:51 GMT
I think my preference is swayed by convention/simplicity. The way things
are done now are just very intuitive for me. When I sit down to write
some code with Lucene, I barley have to think or remember much. It all
sticks. Its mostly all basic Java with few patterns.

Now google has used some cool patterns to make things like Guice pretty
sweet. And because of what Guice does, they are pretty necessary I
think. But every time I go back to work on that code, I have to relearn
a bunch of stuff/conventions. Its not difficult - but its a small brain
annoyance.

One of the reasons I fell in love with Lucene is that its just so
natural and easy to use and yet still so powerful. Not that I'm claiming
the deprecated methods arn't a bit of a pain - but they have never
caused me problems.

Not a fan of static builder methods either. But hey, sometimes they make
sense, so whatever I guess ...

Michael Busch wrote:
> 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
>


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


Mime
View raw message