[
https://issues.apache.org/jira/browse/LUCENE-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117270#comment-13117270
]
Michael McCandless commented on LUCENE-3474:
--------------------------------------------
It would be nice if we could discuss the builder pattern (and other
heated disagreements) without quickly degrading into deadlock. We
need to be able to work through our disagreements so we can get back
"real" improvements to Lucene and Solr. In this case LUCENE-1536 is
an enormous performance gain.
Net/net I don't like the use of the builder pattern for ScorerContext.
It seems like overkill: we only have 3 settings here. Even by the
proponents of the builder pattern this is overkill?
I think chained setters are less readable (see LUCENE-2308).
I do agree 2 booleans in a row is asking for sneaky trouble; we can
add .setX instead (these fields need not be final)? Or the int flags
to the ctor is a great solution too (I think we should do this for
FieldType as well).
Net/net plain old boring java object would work fine here.
And, in general, I don't think we should let the builder pattern seep
into Lucene, for the simple reason that it's obviously controversial.
This is no different from any other controversial change in
open-source...
Also, one can always make a shim layer on top of Lucene that exposes
builder APis for everything? QueryParser, *Query, *Field/Document,
IR, IW, merge policies/schedulers, etc., all could be cutover to
builder APIs "up above" right? If we can safely apply the builder
pattern "on top", ie it need not pollute Lucene's core, why not do
that? We should only make core changes that are not controversial or
must be done in core.
> pass liveDocs Bits down in scorercontext, instead of Weights pulling from the
> reader
> -------------------------------------------------------------------------------------
>
> Key: LUCENE-3474
> URL: https://issues.apache.org/jira/browse/LUCENE-3474
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Robert Muir
> Attachments: LUCENE-3474.patch, LUCENE-3474.patch
>
>
> Spinoff from LUCENE-1536, this would allow filters to work in a more flexible
> way (besides just cleaning up)
--
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: [email protected]
For additional commands, e-mail: [email protected]
