[
https://issues.apache.org/jira/browse/LUCENE-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589490#comment-14589490
]
Uwe Schindler edited comment on LUCENE-6575 at 6/17/15 8:40 AM:
----------------------------------------------------------------
bq. We are not there yet, but please let's not put this chaining issue in the
way of making our queries immutable.
This issue was about improving the API, so it is relevant here. I think making
phrase queries immutable is another thing and was discussed in LUCENE-6531.
bq. And since Cao changed the setters to return "this" in his patch, I pointed
him to this previous discussion.
Robert's main problem was not the chaining, he disagreed with the "fluent"
method names (Java 8+ streams API is using them everywhere now)!
But just returning "this" from a setter is in my opinion a valid simplification
for users of the API. It mainly works around the problem of not having a "with"
operator in java, like Javascript has:
{code:javascript}
with (object) {
setA();
setB();
}
{code}
On the Java side, recent versions of Eclipse perfectly detect & ident those
chaining constructs (because Java 8 requires them to do this, otherwise code
gets indeed unreadable).
I also added builder APIs in recently: {{CustomAnalyzer.builder()}} (see my
talk @ buzzwords;
http://lucene.apache.org/core/5_2_1/analyzers-common/org/apache/lucene/analysis/custom/CustomAnalyzer.html)
and Robert did not complain, because the names were according to fluent API
standard and the formatting in the tests was also fine :-)
was (Author: thetaphi):
bq. We are not there yet, but please let's not put this chaining issue in the
way of making our queries immutable.
This issue was about improving the API, so it is relevant here. I think making
phrase queries immutable is another thing and was discussed in LUCENE-6531.
bq. And since Cao changed the setters to return "this" in his patch, I pointed
him to this previous discussion.
Robert's main problem was not the chaining, he disagreed with the "fluent"
method names (Java 8+ streams API is using them everywhere now)!
But just returning "this" from a setter is in my opinion a valid simplification
for users of the API. It mainly works around the problem of not having a "with"
operator in java, like Javascript has:
{code:javascript}
with (object) {
setA();
setB();
}
{code}
On the Java side, recent versions of Eclipse perfectly detect & ident those
chaining constructs (because Java 8 requires them to do this, otherwise code
gets indeed unreadable).
I also added builder APIs in recently: {{CustomAnalyzer.builder()}} (see my
talk @ buzzwords) and Robert did not complain, because the names were according
to fluent API standard and the formatting in the tests was also fine :-)
> Improve API of PhraseQuery.Builder
> ----------------------------------
>
> Key: LUCENE-6575
> URL: https://issues.apache.org/jira/browse/LUCENE-6575
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Cao Manh Dat
> Priority: Minor
> Attachments: LUCENE-6575.patch, LUCENE-6575.patch
>
>
> From LUCENE-6531
> In current PhraseQuery.Builder API. User must retype field again and again :
> {code}
> PhraseQuery.Builder builder = new PhraseQuery.Builder();
> builder.add(new Term("lyrics", "when"), 1);
> builder.add(new Term("lyrics", "believe"), 3);
> {code}
> Cleaner API :
> {code}
> PhraseQuery.Builder builder = new PhraseQuery.Builder("lyrics");
> builder.add("when", 1);
> builder.add("believe", 3);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
