lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3756) Don't allow IndexWriterConfig setters to chain
Date Wed, 08 Feb 2012 05:00:59 GMT


Shai Erera commented on LUCENE-3756:

Mike, this is purely a style thing. You think that the code is not readable, I think that
it is. If you want, we can ask Lucene committers not to chain lots of set() calls in one line,
or format the code such that lines are not longer than 120 characters.

But if you change IWC's API contract, you force your preferred style on everyone. To that
I cannot agree. There isn't any technical reason to force IWC to return void. If you think
however (and that doesn't seem the case here) that any of the methods should return a different
value, then that's a whole different story.

IMO, if a class returns void in all its methods, and it is a configuration class, it should
be a builder. It's for convenience. When I want, I chain set() calls. Sometimes I have mixed
code, when I want to document the reason for a specific set() call. The point is that I have
the *freedom* to decide how to use the class.
> 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