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 earwin@gmail.com designates
 209.85.219.219 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=W4PgTZquWfInr9smvDNd1hdfvaFfFeX86FLKI3QNAn1/CvGgVoJGqjWjBjmzhTqUq1
         ffmpas8nltXf+M9x52VEeKyxP26t3Fzs0/GehZw20vLdqowMOAJ7L1WZERvsN7lAlibg
         uZcXPQj/3eo5umPIyvtWWqROU1K3kyy6vNFNE=
MIME-Version: 1.0
In-Reply-To: <9ac0c6aa0910030235m4fa09700n76b15156c79252c5@mail.gmail.com>
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>
	 <9ac0c6aa0910030235m4fa09700n76b15156c79252c5@mail.gmail.com>
Date: Sat, 3 Oct 2009 14:13:09 +0400
Message-ID: <59b3eb370910030313j452585e5t1f465181462c46a4@mail.gmail.com>
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
From: Earwin Burrfoot <earwin@gmail.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>> Builder pattern allows you to switch concrete implementations as you
>> please, taking parameters into account or not.
>
> We could also achieve this w/ static "factory" method.  EG
> IndexReader.open(IndexReader.Config) could switch between concrete
> impls (it already does today).
Yes, the choice of 'IW.create(IWSettings, Directory)' VS
'IWSettings.create(Directory)' is purely syntactical (with latter
being more concise, imo), but I was comparing to 'new IW(Settings,
Directory)'.

>>> Call me old fashioned, but I like how the non constructor params are se=
t
>>> 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.
>
> This is a good point: are you allowed to change config settings after
> creating your IndexWriter/Reader?
>
> Today it's ad hoc.
>
> EG IW does not allow you to swap out your deletion policy, because
> it'd be a nightmare to implement.  You also can't swap the analyzer.
> But it does let you change your RAM buffer size, CFS or not, merge
> factor, etc.  We can remove that flexibility (I'm not sure it's
> compelling), so we can make things final.  You can't change read-only
> after opening your IndexReader.  I think it'd make sense to move away
> from changing settings after construction...
I've just remembered some horrible things:

public void setMergeFactor(int mergeFactor) {
  getLogMergePolicy().setMergeFactor(mergeFactor);
}

Let's remove this "flexibility" too?

> But: the "do we disallow changing config settings after construction?"
> question is really orthogonal to the "what syntax do we use for
> construction?" (builder vs config vs zillions-of-ctors).
There's better syntax for both mutable and immutable approach, so it's
not like these two questions are completely orthogonal.

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