[hibernate-issues] [JIRA] (HSEARCH-4677) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiY2MxMzdj... ) / Task ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiY2M... ) HSEARCH-4677 ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiY2M... ) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiY2M... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Follows up on [https://hibernate.atlassian.net/browse/HSEARCH-4601|https://hibernate.atl...]. See the discussion [starting here|https://github.com/hibernate/hibernate-search/pull/3152#issuecomment...]: {quote}> And now, by reading the examples with lambdas, i.e. when the operator instantiation and the add operations are distant from one another, I'm wondering if such syntax isn't requiring an excessive cognitive load for casual readers to figure out what kind of operation this add is performing. I'd say the cognitive load would be reduced if the methods were to be more explicitly named {{and}} and {{or}}. That means getting back to the situation before you de-duplicated all the interfaces, then :) That might be clearer for long chains of {{.add()}}, but  I find it strange to use {{and}}/{{or}} for the very first clause, and that would also feel very redundant, e.g. {{f.and().and( e1 ).and( e2 )}}. It would also prevent developers from writing "generic" functions that simply add multiple clauses to a boolean predicate, without knowing whether it's an {{and}} or an {{or}}; not a big deal, but worth mentioning. {quote} {quote} > In addition to making code more self-explanatory, having specific "{{add}}" methods would be less error-prone when different predicates are used in different {{with(...)}} constructs, as in "Example 228. Easily adding clauses dynamically using with(…) and the lambda syntax". That wouldn't make things less error-prone for {{and}}/{{and}} nesting though, e.g. {{f.and().and( ... ).and( f.nested().and( ... ).and( ... ) )}}. To me that's one more reason to _not_ introduce and {{add}} syntax for {{not}}: make that predicate accept a _single_ inner clause and leave it at that. People can still nest an {{and}} predicate if they want to, and we can always try to "flatten" expressions under the hood with some tricks (which we'll probably need for the {{not()}} predicate anyway).{quote} ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100205- sha1:59a7aeb )