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, <nlis...@gmail.com> wrote:
> 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 <jonat...@jonathangiles.net>
> 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, <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<Boolean> 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
>> > >> <kevin.rushfo...@oracle.com <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,
>> > >> Num-Lock, and
>> > >> maybe Scroll-Lock (although I might defer the latter to a future
>> > >> version
>> > >> since it will be more difficult to test, and doesn't seem as
>> > >> useful).
>> > >>
>> > >> This is currently tracked by JDK-8259680 [1].
>> > >>
>> > >> The proposed API would be something like:
>> > >>
>> > >> public static boolean Platform::isKeyLocked(KeyCode
>> > >> keyCode);
>> > >>
>> > >> One question is whether we should throw an exception if the key
>> > >> state
>> > >> cannot be read on a particular system (e.g., Num Lock on macOS),
>> > >> which
>> > >> is what the similar AWT API does. I don't have a strong opinion
>> on
>> > >> that
>> > >> poont, although I wouldn't want to throw an exception if the
>> > >> keyboard
>> > >> doesn't have the key in question, as long the system is able to
>> > >> read the
>> > >> state accurately.
>> > >>
>> > >> Comments are welcome.
>> > >>
>> > >> -- Kevin
>> > >>
>> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8259680
>> > >> <https://bugs.openjdk.java.net/browse/JDK-8259680>
>> > >>
>> > >
>> >
>>
>
