Improving Method Reference Ergonomics

[Peter Eastham]

Hey Archie,

Sorry if this was off topic for Amber, is there a better email list for
this type of language improvement?

The JPA reference was only for a more common reference point. Not
necessarily that I want that functionality in JPA itself.

Thanks,
-Peter


On Sun, Dec 8, 2024 at 7:31 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Hi Peter,
>
> Slightly off topic: You might be interested in the querystream library,
> which provides a Stream-like wrapper around JPA's Criteria API.
>
> https://github.com/querystream/querystream/
>
> Disclaimer: I'm the author.
>
> -Archie
>
> On Sun, Dec 8, 2024 at 7:53 PM Peter Eastham <petereastham at gmail.com>
> wrote:
>
>> Hi Amber team,
>>
>> Earlier this week I was playing around with fluent API design, and I
>> believe Java could benefit from some improvements to the usage of Method
>> References, I'll keep this short with the following example.
>>
>> Lets take the following JPA Criteria from section 6.3.3 of the
>> Specification, (Only for an example of what an API could begin doing, not
>> should do)
>> CriteriaQuery q = cb.createQuery(Customer.class);
>> Root customer = q.from(Customer.class);
>> Join order = customer.join(Customer_.orders, JoinType.LEFT);
>> q.where(cb.equal(customer.get(Customer_.status), 1)).select(customer);
>>
>> If there was greater access to the Method Reference more implicit
>> information could be passed, reducing the noise,
>> CriteriaQuery q = CriteriaQuery.createQuery(Customer::new)
>>   .leftJoin(Customer::orders)
>>   .where(Object::equals, Customer::status, 1);
>> var result = q.select();
>>
>> Regarding what should be available, the resolved Class and Method name at
>> least, anything else I'd leave up to the feasibility of the change.
>>
>> Thanks,
>> -Peter
>>
>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241208/941119c8/attachment.htm>