askYesNo()

[Thomas Friedrichsmeier]

Hi,

On Wed, 16 May 2018 23:45:36 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> Am Mittwoch, 16. Mai 2018, 21:08:02 CEST schrieb Thomas
> Friedrichsmeier:
> > On Wed, 16 May 2018 17:12:58 +0200
> > meik michalke <meik.michalke at uni-duesseldorf.de> wrote:  
> > > that's an even better idea. i've pushed something for testing, i
> > > just called the new function rk.askYesNo() and modelled its
> > > arguments after askYesNo().  
> > 
> > nice! Seems to work just fine. So with this, we can just do
> > options("askYesNo"=rk.askYesNo), and that's it, right?  
> 
> after some initial checks i'm afraid it's not so easy after all.
> there's some small issues like we'd have to rename the "message"
> argument into "msg" because askYesNo() is hardcoded to call the
> function with "msg = msg".

Ok. Well, it's probably worth following suite on the parameter name,
then, even if it's a bit ugly.

> but the more complex thing is handling the "prompts" argument in a
> sane way. the thing is, if a user doesn't want to use "yes", "no" and
> "cancel", he will set "prompts" accordingly, thus removing the
> default getOption("askYesNo") from the askYesNo() call, which will
> effectively circumvent the use of rk.askYesNo() and alternatively pop
> up a text input window.

I see. Well, that's not really a clever design. OTOH, it does not really
set us back any compared the current / pre-3.5.0 situation.
 
> to also cover those cases, i guess we'll have to mask askYesNo()
> completely with our own function and have it also handle the set
> options accordingly. it is a relatively trivial function, so i'd not
> expect huge surprises here. our function could check if "prompts" is
> a function and call utils::askYesNo() with it if that's a positive --
> that would again produce the text input popup, but we'll not be able
> to take care of custom functions here, will we.
> 
> shall i proceed?

Hm. Note that there are two different "levels" of masking. The first
would be to simply put an askYesNo() into the rkward-package. This
would be called for user scripts having askYesNo(). However, it would
_not_ be called for uses of askYesNo() from inside any packages.
Unlikely to be terribly useful, if you ask me.

In a few select cases we take a more radical approach, and _replace_
functions in "base" R packages. While unavoidable in a few cases, this
is something that we should try to avoid wherever possible. It's just
one of the things that _may_ get us into trouble on any upgrade of
R(*). In this case, I'd say, R provides a mostly sane mechanism to set
our own hook for the most important use case (via options), and at
least we don't fail completely for the other cases. So let's rather
play it safe, IMO.

Regards
Thomas

(*) E.g. even "harmless" changes such as renamed parameters would be
incompatible (and the same has happened to us, before). Also, for
example, it's entirely conceivable that R core will eventually come to
realize that the mix-up of prompts and handler function was not really
a good choice, and patch that by adding another parameter
"handler=options("askYesNo")", which will override the interpretation
of prompts, if given. Or something else we do not anticipate right now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20180517/8a1bdf3b/attachment.sig>