Proposal: Focus Traversal API

Andy Goryachev andy.goryachev at oracle.com
Mon Oct 21 21:58:43 UTC 2024


I don't want to limit the API choices: someone might come around and say "we want to add two more directions - clockwise and counterclockwise".  The any code that switches on an enum value without a default case would fail at run time (a known footgun).

I don't understand why anyone want to switch on method references or "modify control flow" where these APIs are clearly transmit-only so to speak.  I just see no use case.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strauß <michaelstrau2 at gmail.com>
Date: Monday, October 21, 2024 at 14:47
To:
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Proposal: Focus Traversal API
> Also, there seems to be little utility in creating the directionality enum - the only reason to do so would, in my opinion, be within the context of a traversal policy, something that appeared to be very controversial.  I can't but notice how the example you gave tries to solve the same problem the traversal policy would solve.

My example doesn't solve anything, it merely shows that encoding a
method parameter in six different versions of the same method doesn't
compose well, and has worse ergonomics than just encoding the
parameter as an actual parameter.

The reasons I gave are:
1. You can't switch() on a method reference, therefore applications
that want to use the new API and abstract over it will have to
re-invent the enum anyways.
2. You can't modify the control flow by selecting a different parameter.

I don't want to discuss the traversal policy proposal here, I am only
commenting on the API that you propose. There is no precedent in
JavaFX for providing six different methods for what is essentially a
parameter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241021/a051f390/attachment-0001.htm>


More information about the openjfx-dev mailing list