On Oct 2, 2009, at 10:18 PM, Earwin Burrfoot <ear...@gmail.com> wrote:
Call me old fashioned, but I like how the non constructor params
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
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
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 <ear...@gmail.com>
wrote:
On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <u...@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/Кирилл Захаренко (ear...@gmail
.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---
------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
