[
https://issues.apache.org/jira/browse/LUCENE-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202446#comment-13202446
]
Michael McCandless commented on LUCENE-3736:
--------------------------------------------
bq. If you look at the test cases, the code is much less verbose and better
readable.
Well, you separated each method call onto a separate line, so, it'd
look basically the same without chaining? If only all chained API
consumers followed your approach...
To be clear: what I dislike about chaining is it creates ambiguity
in how you write the code that consumes our APIs.
You().can().do().this(). Or, you().
can().
do().
this(). Or maybe you().can().
do().this().
Ambiguity is very bad, especially in open-source dev: it invites
bikeshed wars, harming communities by dividing them, spending precious
time debating what from the outside would seem like trivial
differences.
bq. If somebody wants to change this, he can do this in another issue called
"remove all builders from Lucene"
The first API I would fix is IndexWriterConfig; its setters should not
be chainable, because now we get code like this:
{noformat}
IndexWriter writer = new IndexWriter(dir, newIndexWriterConfig(
TEST_VERSION_CURRENT, new
MockAnalyzer(random)).setMaxBufferedDocs(2).setMergePolicy(newLogMergePolicy()));
{noformat}
Code is already hard enough to read... we should not make it even
harder by enabling big hard-to-read compound expressions like this.
This phenomenon is [unfortunately] human nature, and also well outside
of software development; see
http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality ... the
less important the ambiguity the more brutal the bike shed wars will
be. You see this also in Theodor Geisel ("Dr Seuss")'s delightful
Sneetches (the stars on their stomachs), his Butter Battle Book (which
side to butter the bread on), which end of the egg to crack (the
Lilliputians in Gulliver's Travels), etc. It's not an uncommon
problem :)
Battles over code styling is a great example of this phenomenon, and
fortunately we long ago adopted a standard for Lucene so we don't
argue (much!) about code style. There is one way and there is no
(little!) ambiguity left.
So I don't want to add any more chainable methods in Lucene. It
creates an unnecessary ambiguity and I don't like where that will lead
us. We should reduce ambiguity whenever we can: there should
generally be one obvious way to do something.
> ParallelReader is now atomic, rename to ParallelAtomicReader and also add a
> ParallelCompositeReader (that requires LogDocMergePolicy to have identical
> subreader structure)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3736
> URL: https://issues.apache.org/jira/browse/LUCENE-3736
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: core/index
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-3736.patch, LUCENE-3736.patch, LUCENE-3736.patch
>
>
> The plan is:
> - Move all subreaders to ctor (builder-like API. First build reader-set, then
> call build)
> - Rename ParallelReader to ParallelAtomicReader
> - Add a ParallelCompositeReader with same builder API, but taking any
> CompositeReader-set and checks them that they are aligned (docStarts
> identical). The subreaders are ParallelAtomicReaders.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
