Allow lamba-like synax for methods

Steve Barham steve at ethx.net
Wed Jun 21 22:07:03 UTC 2023


Hi Anatoly,

My feedback on your proposal would be to ask what you want, rather than to
suggest how you might achieve what you want with (ab)use or extension of
existing syntax.

There have been prior discussions of ‘concise method’ declarations which
would be worth reviewing, prior to your first suggestion. My understanding
thus far is that the value returned from golfing away a line feed and brace
is lacking.

With respect to your second part; if named parameters and default parameter
values (both goals I would love to see!) were implemented, I suspect it
would be better for Java to support them through a clear and unambiguous
form, rather than as a neat hack using existing syntax.

My general perception from lurking is that syntax should come last in
suggestions, not first.

Cheers

Steve


* this is a very personal supposition, but I feel that named parameters and
default values, if they are to come, have a substantial degree of overlap
with deconstruction patterns, record like classes and reconstructors



On Wed, 21 Jun 2023 at 22:40, Anatoly Kupriyanov <kan.izh at gmail.com> 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 Account setName(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(), 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/292e2e17/attachment-0001.htm>


More information about the amber-dev mailing list