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 Lock is " + (on ?
"on" : "off")),
() -> label.setText("Check Caps Lock"));
In practical terms, a key event listener would need to be added to the
password field to react to Caps Lock presses, and that will call the code
above.
I think that this is the best option.
On Sun, Jan 17, 2021 at 8:10 PM Frederic Thevenet
wrote:
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:
isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> {
// The num_lock key exists on the current platform
if (locked){
// React to the key being locked
} else {
// Or to the key not being locked
});
On 17/01/2021 18:31, Jonathan Giles wrote:
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 state.
-- Jonathan
(Tapped on a touch device)
On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
mailto:thevenet.f...@free.fr>> wrote:
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 runtime, on said platform.
With the other two proposed solution (three-state return and Checked
exception) the API itself reminds its would be consumer that they
should
consider a case where the operation is invalid.
I'm personally not keen on checked exceptions in such a scenario
either,
as it would require an extra API to check for the existence of a
given
key on the current platform, or condemn developers to implement
conditional logic via exception catching (or require developer to
know
what specific keys exists on what platform before-hand to do the
check).
Given all that, my personal preference would go to a three state
return
solution.
On that topic, is there anything that would preclude the use of an
Optional to represent these three states, if we want to
avoid
introducing new enums? It seems to me its semantics aligns quite
nicely
with the problem at hand.
Fred
On 16/01/2021 17:41, Kevin Rushforth wrote:
> 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 don't generally like checked exceptions; we don't
define
> any such exceptions in JavaFX and I wouldn't want to start now.
>
> -- Kevin
>
>
> On 1/16/2021 12:46 AM, Jonathan Giles wrote:
>> 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, NOT_PRESENT }
>>
>> I'll be the first to argue against yet another enum, but I
wanted to
>> throw this out there as an alternate approach that avoids the
needs
>> for checked exceptions (which is what I assume is meant by
'throw an
>> exception', as opposed to throwing a runtime exception).
>>
>> -- Jonathan
>>
>> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth
>> mailto:kevin.rushfo...@oracle.com>
>> wrote:
>>
>> For JavaFX 17, I am planning to add a minor enhancement to
read the
>> state of the keyboard lock keys, specifically, Caps-Lock,
>>
