I also think that the suggestion of using Optional is a very
good one, and more clearly expresses the "unknown" case without having
to invent a new enum and without the problems that throwing an unchecked
exception could cause.
Thanks.
-- Kevin
On 1/18/2021 12:20 AM, Nir Lisker wrote:
Looking at the use case for this request, which is to warn the user while
typing in password fields, I tried to write some simple code for it using
the Optional approach:
Optional result = Platform.isKeyLocked(KeyCode.CAPS+LOCK);
result.ifPresentOrElse(on -> label.setText("Caps
Ah, got it! That teach me to reply before 7am and before the coffee hits!
This might be a reasonable approach in that case. Certainly it does away
with the need for the enum and the exception.
-- Jonathan
(Tapped on a touch device)
On Mon, 18 Jan 2021, 6:59 am Nir Lisker, wrote:
> I think
I realize that my suggestion was somewhat unclear, apology about that.
I wasn't suggesting that we return null to count as the third state, but
indeed that we leverage the isPresent state of the optional, alongside
with the two states provided by the Boolean, e.g:
I think Frederic meant that the Optional is empty in the case where you
can't reliably get the state of the key, otherwise the true and false
values are for the on and off states. The Optional itself is never null.
On Sun, Jan 17, 2021 at 7:31 PM Jonathan Giles
wrote:
> A method returning
A method returning Optional should never return null, as that undoes the
contract that Optional is supposed to represent, which is to avoid NPEs by
never being null itself, only empty in the absence of a returned value. For
this reason, an Optional should be considered two state rather than three
Hi,
From the perspective of the application developer, I think throwing a
runtime exception if the key does not exists on a given platform is
potentially risky, as the API provided no hints that a given key might
not exists an other platforms, and this oversight will only manifest
itself at
Hi Jonathan,
Thanks for the suggestion. I thought about it as well. We could do that,
but it seems like overkill. I'll reconsider if enough others favor the
idea. As for the exception, my thinking is to use
UnsupportedOperationException, which is what the equivalent AWT method
uses. FWIW, I
Let's separate out the questions of what to do if we can't reliably get
the state of a key on a particular platform versus what to do if the key
isn't present (on a system where we could get the state if it were there).
The latter case seems clear: returning false is the right answer, since
Hi friends,
Just to throw out an alternate API approach (which I would not go anywhere
near close to saying is a better approach), we could consider a three-value
enum getter API:
public static KeyLockState Platform::getKeyLockState(KeyCode keyCode);
Where KeyLockState = { LOCKED, NOT_LOCKED,
What do the methods that check if a mouse button is pressed, but the button
does not exist on the mouse, do?
Maybe it's a hint for consistency.
On Sat, Jan 16, 2021 at 5:09 AM Dan Howard wrote:
> Please no additional exceptions. It only makes me think in a platform
> specific way. Better would
Please no additional exceptions. It only makes me think in a platform
specific way. Better would be an extra method that can I can check if
key exists. But if the key exists or is not pressed it should simply
return false. IMO
On 1/15/2021 12:39 PM, Kevin Rushforth wrote:
For JavaFX 17, I am
12 matches
Mail list logo
