Hi all,
I like the functional style of apply(). For me it seems best as it's
flexible and has a small footprint.
And as for the condition part we could just add overloaded version with
Predicate<> argument, like this:
public ObjectSelect<T> apply(Predicate<ObjectSelect<T>> cond,
Consumer<ObjectSelect<T>> op) {
if(cond.test(this)) {
op.accept( this );
}
return this;
}
John's example could be done like this:
.apply(q -> yearRange != null, q -> q.and(APPOINTMENT_DATE.gt(yearRange)))
On Mon, Jul 8, 2024 at 2:30 PM Jurgen Doll <[email protected]> wrote:
> Hi All
>
> What about borrowing "apply" from Function/UnaryOperator ?
> Then we'll have the following API added to Expression:
>
> /**
> * Apply the provided UnaryOperator function to the current Expression.
> */
> public Expression apply( UnaryOperator<Expression> op )
> {
> return op.apply( this );
> }
>
> And the same for ObjectSelect but passing a Consumer instead:
>
> /**
> * Apply the provided Consumer to the current ObjectSelect.
> */
> public ObjectSelect<T> apply( Consumer<ObjectSelect<T>> op )
> {
> op.accept( this );
> return this;
> }
>
> In addition I'd still very much like to have "apply" API that takes a
> boolean parameter as well. For simple cases this will allow user code to
> be more concise without the ternary pattern clutter.
>
> Thoughts, tweaks, likes or objections ?
>
> Regards
> Jurgen
>
--
Best regards,
Nikita Timofeev
