Follows up on [https://hibernate.atlassian.net/browse/HSEARCH-4601|https://hibernate.atlassian.net/browse/HSEARCH-4601|smart-link].
See the discussion [starting here|https://github.com/hibernate/hibernate-search/pull/3152#issuecomment-1220534703]:
{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}}/{{orand}} 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.andnested().addand(...).addand(...) )}}. That being said, I'd argue
> For the fluent syntax is more suited forthcoming {{not}} predicate (HSEARCH-4645), renaming {{add}} to short chains; I’d use something like {{.withandNot}} for longer chains spanning many lines of code may also be more explicit.
For now, ITo me that'll uses one more reason to _not_ introduce and {{andadd}}/ syntax for{{ornot}} 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} |
|
