Improving Method Reference Ergonomics

[Maurizio Cimadamore]

Hi,
Project Babylon might provide a slightly different path to get where you 
want to go. Look at the examples discussed in this great article by Paul:

https://openjdk.org/projects/babylon/articles/linq

With code reflection, the compiler reifies the entire expression 
`Customer::new` (including all the symbolic references) into an instance 
of a code model (`Op`) which can then be dissected/inspected/transformed 
at runtime as you see fit.

I agree that, as others have said, just doing point-improvements on how 
_all_ method references are represented by the runtime isn't going to 
cut it -- what you want is the source model available, more or less 
unchanged, at runtime -- which is the goal of Project Babylon's code 
reflection.

Cheers
Maurizio

On 09/12/2024 01:52, Peter Eastham 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