> On Jul 5, 2024, at 9:37 AM, Michael Gentry <blackn...@gmail.com> wrote:
>
> This was my initial thought about using the "map" operator. I do like the
> fluent pattern, but not sure map is the way to go there.
Since you can apply any operation to the query (ordering, prefetches,
qualifiers), the name has to be generic. But yeah, "map" is not ideal as we are
not producing a new object (as we would in DFLib), but rather adding more stuff
to the same query object. So "add(..)" suggested by Jurgen may actually be ok.
I can think of one other alternative that underscores mutability and the fact
that you can make an arbitrary change in the lambda: "config(..)"
> On Jul 4, 2024, at 9:25 AM, Jurgen Doll <jur...@ivoryemr.co.za> wrote:
> The downside of my proposal is that it doesn't handle the else branch
> directly I suppose.
> Although one could do:
>
> .addif( !c, q -> q.and(exp2) )
> .addif( c, q -> q.and(exp1) )
>
> Which may be more readable(?), depending on the complexity of exp1 and exp2,
> than:
>
> .map( q -> c ? q.and(exp1) : q.and(exp2) )
>
> We could also have both forms in ObjectSelect and Expression:
>
> .???( boolean, Consumer/UnaryOperator ) // for simple cases
> .???( Consumer/UnaryOperator ) // for complex cases
Semantically, it seems that the "if" flavor is better combined with Consumer,
while "map/add/config" flavor requires a return statement (i.e.,
UnaryOperator). The latter is not too hard on the users, as ObjectSelect
returns self on all mutation ops. So I still feel the "if" flavor is redundant.
Thanks
Andrus
