Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiOWMwOGM3... ) / Task ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiOWM... ) HSEARCH-4677 ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiOWM... ) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiOWM... ) 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} Another solution {quote}> In addition to making code more self-explanatory, having specific "{{add}}" methods would be to alter conventions less error-prone when different predicates are used in different {{with(...)}} constructs , i as in "Example 228. e Easily adding clauses dynamically using with(…) and the lambda syntax". to use That wouldn't make things less error-prone for {{and}}/{{ or and }} as the name of the lambda parameter ( nesting though, e.g. {{f.and(). with( and -> (... ) }}). That would reduce the cognitive load when using {{with}}, at least, but obviously not when using the fluent syntax {{ and( f. and nested (). add and (...). add and (...) ) }}. That being said, I'd argue For now, I To me that ' ll use s one more reason to _not_ introduce and {{ and add }} / syntax for {{ or not }} as the name of the lambda parameter in tests : make that predicate accept a _single_ inner clause and examples leave it at that. People can still nest an {{and}} predicate if they want to , and I'll open another ticket we can always try to re-evaluate "flatten" expressions under the problem before hood with some tricks (which we release 6 'll probably need for the {{not()}} predicate anyway). 2.0.Final. {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 )