Allow lamba-like synax for methods

Brian Goetz brian.goetz at oracle.com
Wed Jun 21 23:54:11 UTC 2023


There's already a JEP draft on this:
https://openjdk.org/jeps/8209434

But, it's low priority, needs a lot of work, and honestly, the "lambda 
form" (single expression form) is the less interesting part of the JEP.  
Far more interesting is the part where you can delegate via method 
references.

FWIW, what you've proposed here is not one feature, but at least four:

  - lambda-style method declaration (reasonable, but low priority)
  - inferred method return type (never going to happen, sorry)
  - inferred method parameter types (never going to happen, sorry)
  - a new object literal syntax





On 6/21/2023 5:40 PM, Anatoly Kupriyanov wrote:
> Not sure if it is the right mail list, please advise if there is a 
> better place to give suggestions about Java language.
>
> I suggest using lamba-like syntax for method implementation. Suppose 
> you have a code like this:
>
> final class Account { private final int id; private String name; 
> public Account(int id) { this.id = id; } public int getId() { return 
> id; } public String getName() { return name; } public 
> AccountsetName(String name) { this.name = name;
> return this; }
> @Override public String toString() { return "Account{id=" + id + ", 
> name='" + name + '\'' + '}'; } @Override public boolean equals(Object 
> o) { if (this == o) return true; if (o == null || getClass() != 
> o.getClass()) return false; Account account = (Account) o; return id 
> == account.id; } @Override public int hashCode() { return 
> Objects.hash(id); } } void transfer(Account from, Account to, int 
> amount) { transfer(from, to, amount, 0); } void transfer(Account from, 
> Account to, int amount, int commission) { 
> System.out.printf("Transferred %s -> %s %s (commission: %s)", from, 
> to, amount, commission); }
> void main() {
> //there is no way to see here which one is "from" which one is "to". 
> Where is the amount, where is the commission?
> transfer(new Account(1), new Account(2), 100); transfer(new 
> Account(2), new Account(1), 200, 5);
> }
> The lambda syntax allows reducing boiler-plate code significantly and 
> new possibilities like named parameters and default parameter values. 
> And it is syntactic sugar, just applying the same rules which are used 
> for lambdas instead of usual method definitions. Like this:
>
> final class Account { private final int id; private String name; 
> Account(int id) -> this.id = id; getId() -> id; getName() -> name; 
> setName(String name) -> {this.name = name; return this; } toString() 
> -> "Account{id=" + id + ", name='" + name + '\'' + '}'; equals(o) -> { 
> if (this == o) return true; if (o == null || getClass() != 
> o.getClass()) return false; Account account = (Account) o; return id 
> == account.id; }
> hashCode() -> Objects.hash(id); }
> interface TransferParams {
> //required params with compile-time guarantee
> Account from(); Account to(); int amount();
> //optional param with mandatory default
> default commission() -> amount() / 20;
> // desugared "/default int commission() {return amount() / 10;}"/
> }
> void transfer(TransferParams p) { System.out.printf("Transferred %s -> 
> %s %s (commission: %s)", p.from(), p.to <http://p.to>(), p.amount(), 
> p.commission()); }
> void main() {
> //this is very similar to single-method interface like 
> @FunctionalInterface but for multiple methods hence it's using a 
> "named" lambdas
> transfer({from() -> new Account(1); to() -> new Account(2); amount() 
> -> 100;}); transfer({from() -> new Account(2); to() -> new Account(1); 
> amount() -> 200; commission() -> 5;});
> }
> //desugared would be something like that:
> /transfer(new TransferParams() { @Override public Account from() { 
> return new Account(1); } @Override public Account to() { return new 
> Account(2); } @Override public int amount() { return 100; } });/
>
> -- 
> WBR, Anatoly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230621/7c018afe/attachment-0001.htm>


More information about the amber-dev mailing list