Hi Andrus
I'm curious as to your reluctance to redundancy in this case ?
A few points to consider:
1. This is entirely a convenience API. It's goal is to inline code as
smoothly as possible, making it more concise and readable. The resulting
code should have as few grammatical markers and clutter as possible.
2. The consumer parameter in ObjectSelect "apply" cannot be used in a
ternary, so the lambda has to be enclosed in braces:
.apply( q -> {
if ( withAttachments ) q.prefetch( Message.ATTACHMENTS.joint() );
})
2a. Of course the Consumer could be changed to a UnaryOperator which would
allow using a ternary:
.apply( q -> !withAttachments ? q : q.prefetch(
Message.ATTACHMENTS.joint() ) )
This is better than before, but this does allow for the entire query to be
replaced/substituted.
Is this behavior then a feature or a bug ? Is it a good idea to allow
this ?
My perspective is that this is not ideal. What do you think ?
2b. The alternative is to have an extra boolean parameter then which
results in:
.apply( withAttachments, q -> q.prefetch( Message.ATTACHMENTS.joint()
) )
This then accomplishes the API goals without allowing the query to be
replaced.
3. This is a straightforward API with very simple implementation, where as
can be seen above the redundancy fulfills a particular purpose.
Having said all that, if 2a with its consequences are desirable, then I
suppose we don't need the boolean method.
Thanks, regards
Jurgen
On Tue, 09 Jul 2024 17:45:58 +0200, Andrus Adamchik <aadamc...@gmail.com>
wrote:
I am +1 on "apply" as the name (much better than "config"!) But I really
think the flavor with the boolean parameter is redundant.
Andrus
On Jul 8, 2024, at 6:29 AM, Jurgen Doll <jur...@ivoryemr.co.za> 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
