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 c
Hi Michael
Sorry I wasn't clear. What I meant is with an EXTRA boolean parameter like
in my original API proposal, like so:
public ObjectSelect apply( boolean onCondition, Consumer op )
{
if ( onCondition ) op.accept( this );
return this;
}
On Tue, 09 Jul 2024 17:11:33 +0200, Michae
Hi Nikita
That's an interesting suggestion with the Predicate parameter. I gave it
some thought and came up with the following concern.
Consider that ObjectSelect is a builder and that the fluent method
invocations can happen in "kind of" any order. So then if they're
rearranged it may re
ange != null, e -> e.and( APPOINTMENT_DATE.gt(yearRange)
) );
Which in my mind is clear, concise, and doesn't have side effects like
"AND 1=1".
Thanks for this suggestion though.
Regards
Jurgen
--- Forwarded message ---
From: "John Huss"
To: dev@cayenne.apac
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 wrote:
>
> Hi All
>
> What about borrowing "apply" from Function/UnaryOperator ?
> Then we'll have the followin
On Mon, Jul 8, 2024 at 4:30 AM Jurgen Doll wrote:
> 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.
>
Hi Jurgen!
In general, I'd like to avoid
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 apply(Predicate> cond,
Consumer> op) {
if(cond.test(th
FWIW, when I need something like this for the WHERE part of a query I do it
with the ternary operator and a static import of ExpressionFactory (which
your IDE can add for you), like:
.and(yearRange != null ? APPOINTMENT_DATE.gt(yearRange) : expTrue())
I don't think there is a good alternative to
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 op )
{
return op.apply( this );
}
And the same for
> On Jul 5, 2024, at 9:37 AM, Michael Gentry 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 g
On Thu, Jul 4, 2024 at 7:26 AM Jurgen Doll wrote:
> I'm hesitant about using "map" for the method name as that implies
> changing object A into object B, like in the stream API, so I don't think
> that's a good fit. Also it may be a bit confusing in Expression as
> there's
> a transform( Function
Hi Andrus and others
I'm glad you like the idea.
I'm hesitant about using "map" for the method name as that implies
changing object A into object B, like in the stream API, so I don't think
that's a good fit. Also it may be a bit confusing in Expression as there's
a transform( Function ) m
Hi Jurgen,
I support the idea behind this API. Let's discuss the shape of it though.
In DFLib (a completely unrelated library that I am working on), we solved a
similar problem with a more generic "map(..)" method that performs an arbitrary
transformation on the object, that can include condit
Hi All
I really like the fluent style in Cayenne 4.
However I found that sometimes the fluent style in my code needs to be
interrupted if some condition has to be tested before configuring the
select any further, which then breaks the nice flow of code.
So I suggest adding the following AP
14 matches
Mail list logo
