[
https://issues.apache.org/jira/browse/LUCENE-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117320#comment-13117320
]
Michael McCandless commented on LUCENE-3474:
--------------------------------------------
bq. I don't like the idea of shying away from a change just because it's
controversial. Sometimes its necessary to shake things up with new ideas.
+1 I'm all for pushing new ideas that make good, hard improvements to
Lucene (like LUCENE-1536).
bq. you seem to be asking for those who advocate a builder like API here to
compromise and for those who don't want such an API, to not? Thats a tough pill
to swallow.
I am in fact asking for that, because largely Lucene does not adopt
the builder pattern today, the builder pattern is relatively new and
trendy, vs Lucene's codebase, and now we see it seeping in, in various
places/patches/etc. Not only is it new, it's also controversial
amongst the committers.
I think it's also reasonable because you can naturally layer the
builder API on top of a simple java APIs, but not really vice/versa.
One could create a very nice shim "Lucene builder APIs" library.
It need not be in our core APIs.
This way apps that love the builder pattern can use the builder shim;
those that don't like them can use the plain java APIs.
As other "popular" patterns try to seep into Lucene, I think we should
also take a cautious stance: we should not apply a pattern just
because it exists and has become popular; we should see strong
technical benefits to Lucene before doing so.
So, stepping back, "adopting the builder pattern in Lucene's APIs" is
the overall change I'm talking about, and I think that is a big
change.
bq. Also, this API feels to me to be a lot more internal, so whether or not
builders could be built on top of more outward facing concepts like
QueryParsers, Field/Document etc, seems a different issue?
Right this is an internal API, but for example if you build custom
queries/scorers you can still use a builder shim on top of Lucene's
core ScorerContext. It could be part of this builder shim library
too.
Really "Lucene should adopt the builder pattern" to me is a big
change, and it's a codebase-wide, global decision. It's actually very
similar to passionate disagreements on whitespace, and this is why we
(thankfully) have a hard standard on what our whitespace looks like.
Otherwise we'd be having huge arguments about whether parens should be
surrounded by whitespace on every patch.
So net/net I don't think Lucene should adopt the builder pattern, for
internal or external APIs. Just build a shim library on top.
> 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]
