thomas.friedrichsmeier at ruhr-uni-bochum.de
Wed May 9 07:15:00 UTC 2018
On Tue, 08 May 2018 15:33:19 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> however, i would still argue that users of askYesNo() do not
> anticipate it returning NULL, because TRUE, FALSE and NA is all
> that's documented.
Yes, absolutely, I did not mean to argue against that.
In fact, I'm wondering whether it would make sense - or more precisely
whether it would be worth the trouble - to adjust rk.show.question()
itself to NA as return value for "Cancel". (For better drop-in
compatibility with askYesNo(), but, admittedly NA seems a better choice
than NULL, here).
Of course for backwards compatibility, that would mean adding a new
function with that return value (say rk.ask.question()), deprecating
rk.show.question(), and removing it in the future...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the rkward-devel