lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3756) Don't allow IndexWriterConfig setters to chain
Date Tue, 07 Feb 2012 20:16:59 GMT


Michael McCandless commented on LUCENE-3756:

bq. The fact that the API allows chaining (a builder pattern I think?) doesn't mean you need
to use it.

The problem is, I haven't yet seen a usage of this chaining that is
is "good".

I know this chaining is apparently a core part of being a builder API,
which confuses me because I think sometimes the separate builder is
justified yet chaining doesn't seem necessary (eg FST.Builder).

Sure, with IWC's chaining, it's faster to write, less LOC, feels good,
etc., but the result is large compound expressions in one line, and
less *readable* code, and I think, especially in open-source
development, readability is more important than writability.

Does anyone think the example above is more readable than the
non-chained alternative?  Look at all our tests, where we inline the
creation/building of an IWC: can you find one where chaining actually
helps readability?

Chaining offers a dangerous, toxic degree of freedom/ambiguity that I
think can only cause our source code, but more importantly our
community, harm.

> Don't allow IndexWriterConfig setters to chain
> ----------------------------------------------
>                 Key: LUCENE-3756
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
> Spinoff from LUCENE-3736.
> I don't like that IndexWriterConfig's setters are chainable; it
> results in code in our tests like this:
> {noformat}
> IndexWriter writer = new IndexWriter(dir, newIndexWriterConfig( TEST_VERSION_CURRENT,
new MockAnalyzer(random)).setMaxBufferedDocs(2).setMergePolicy(newLogMergePolicy()));
> {noformat}
> I think in general we should avoid chaining since it encourages hard
> to read code (code is already hard enough to read!).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message