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 74.125.92.27 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:x-mailer:mime-version:subject:date
         :references;
        b=kzrMTUU+mkjF9CT0V/ousN0V5+k/LBwGHL88SR2WvQuzEZ8sPOnzjZ8kfU8ftlk7RU
         jSmtPVDmNyEyOSf5aZGRZWy/hQC+v5tkn7S1AR6nkGFesdZF9cDbrRKrfFy77pDV++HH
         X5prvs4wcQsd8VYFc/szk/txQ5iciRlNychGk=
Message-Id: <0A1FF3C7-28FD-49B6-B304-43519B43073C@gmail.com>
From: Mark Miller <markrmiller@gmail.com>
To: "java-dev@lucene.apache.org" <java-dev@lucene.apache.org>
In-Reply-To: <59b3eb370910021918h797027e8qf30761dd22e8f6e5@mail.gmail.com>
Content-Type: text/plain;
	charset=utf-8;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPhone Mail 7A400)
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
Date: Fri, 2 Oct 2009 23:25:14 -0400
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>


On Oct 2, 2009, at 10:18 PM, Earwin Burrfoot <earwin@gmail.com> wrote:

>> Call me old fashioned, but I like how the non constructor params =20
>> are set
>> now.
> And what happens when you index some docs, change these params, index
> more docs, change params, commit? Let's throw in some threads?
> You either end up writing really hairy state control code, or just
> leave it broken, with "Don't change parameters after you start pumping
> docs through it!" plea covering your back somewhere in JavaDocs.
> If nothing else, having stuff 'final' keeps JIT really happy.
>
>> And for some reason I like a config object over a builder pattern for
>> the required constructor params.
> 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 =20
> that's just me :)

Nope. So far it's you and a couple others ;)

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

>>> wrote:
>>>
>>>> On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <uwe@thetaphi.de> =20
>>>> wrote:
>>>>
>>>>>> It is also probably a good idea to move various settings =20
>>>>>> methods from
>>>>>> IW to that builder and have IW immutable in regards to =20
>>>>>> configuration.
>>>>>> I'm speaking of the likes of setWriteLockTimeout, =20
>>>>>> setRAMBufferSizeMB,
>>>>>> setMergePolicy, setMergeScheduler, setSimilarity.
>>>>>>
>>>>>> IndexWriter.Builder iwb =3D IndexWriter.builder().
>>>>>>   writeLockTimeout(0).
>>>>>>   RAMBufferSize(config.indexationBufferMB).
>>>>>>   maxBufferedDocs(...).
>>>>>>   similarity(...).
>>>>>>   analyzer(...);
>>>>>>
>>>>>> ... =3D iwb.build(dir1);
>>>>>> ... =3D iwb.build(dir2);
>>>>>>
>>>>> A happy user of google-collections API :-) These builders are =20
>>>>> 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 =20=

>>>> of
>>>> them are deprecated! How on earth am I supposed to create this =20
>>>> thing?
>>>> 2. If someone creates IW with some reflectish javabeanish tools - =20=

>>>> he's
>>>> busted. Not that I'm feeling compassionate for such a person.
>>>>
>>>>
>>>>> I like Earwin's version more. A builder is very flexible, =20
>>>>> because you can
>>>>> concat all your properties (like StringBuilder works with its =20
>>>>> append method
>>>>> returning itself) and create the instance at the end.
>>>>>
>>>> Besides (arguably) cleaner syntax, the lack of which is =20
>>>> (arguably) a
>>>> curse of many Java libraries,
>>>> it also allows us to return a different concrete implementation =20
>>>> 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/=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =
=D0=97=D0=B0=D1=85=D0=B0=D1=80=D0=B5=D0=BD=D0=BA=D0=BE (earwin@gmail=20
>>>> .com)
>>>> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
>>>> ICQ: 104465785
>>>>
>>>> ---=20
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---=20
>>> ------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --=20
> Kirill Zakharenko/=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =
=D0=97=D0=B0=D1=85=D0=B0=D1=80=D0=B5=D0=BD=D0=BA=D0=BE =
(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