[R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

Stefan Lenz IMBI |enz @end|ng |rom |mb|@un|-|re|burg@de
Mon Apr 6 17:25:35 CEST 2020


Yes, as I wrote earlier, I would like to imitate the behaviour of loading an R package

 juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
 myJuliaFunction()

like R:

 library("MyRPackage") # exports myRFunction
 myRFunction()

I could return an environment, such that the call becomes

 attach(juliaUsing("SomeJuliaPackage"))
 myJuliaFunction()

But calling juliaUsing(), as it is now, takes care that if a package is imported a second time,
the first data base is removed via detach().
This way, users do not have to worry about calling juliaUsing() mutliple times in a script, same
as R users don't have to worry about calling library() multiple times.
If you call the code with attach() multiple times and do not detach, you get your screen cluttered with
warnings "xxx is masked by xxx".
So I would say it would decrease user-friendliness to return an environment.
I also want to make explicit, that the call to attach
occurs only once in my code, after creating the environment:

 envName <- paste0("JuliaConnectoR:", absoluteModulePath)
 if (envName %in% search()) {
 detach(envName, character.only = TRUE)
 }
 attach(funenv, name = envName)

This code is only called by juliaImport() and juliaUsing(), which aren't called by any other function of 
the package
and are supposed to be called directly by the user.

Stefan 
 
----------------ursprüngliche Nachricht-----------------
Von: Duncan Murdoch [murdoch.duncan using gmail.com]
An: Dirk Eddelbuettel [edd using debian.org], Ben Bolker [bbolker using gmail.com]
Kopie: List r-package-devel [r-package-devel using r-project.org]
Datum: Mon, 6 Apr 2020 11:00:09 -0400
-------------------------------------------------
 
 
> On 06/04/2020 10:49 a.m., Dirk Eddelbuettel wrote:
>> 
>> On 6 April 2020 at 08:38, Ben Bolker wrote:
>> | Just reply to the CRAN maintainers and explain this situation. It¨s
>> | slightly buried, but the e-mail you received does say:
>> |
>> | > If you are fairly certain the rejection is a false positive, please reply-all to this
>> | > message and explain.
>> 
>> True, but this misses the "Letter of the law" versus the "Spirit of the law".
>> 
>> It might be worth mentioning that use of attach() is seen, to find one poor
>> analogy, pretty much like use of global variables these days. "Just because
>> you could does not mean you should".
>> 
>> See e.g. one of the first google hits for 'r do not use attach' here:
>> https://stackoverflow.com/questions/10067680/why-is-it-not-advisable-to-use-attach-in-r-and-what-should-i-use-instead
> 
> I don't have a strong opinion on this: the proposed use seems to be no 
> worse than library() or require(). Those are fine for users to use, but 
> are discouraged in a package. If the attach() never happens without an 
> explicit request from the user (and that's what it sounds like), I'd say 
> it's probably okay.
> 
> However, there is an easy workaround: just return the environment 
> without attaching it. Then the user has the choice of attaching it, or 
> using it as a prefix when they call the functions in it. So it's not as 
> though this will destroy the utility of the package if Stefan isn't 
> allowed to call attach().
> 
> Duncan Murdoch
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 


-- 

Stefan Lenz

Institut für Medizinische Biometrie und Statistik
Medizinische Fakultät / Universitätsklinikum Freiburg

Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg

Tel.: 0761/203-6670
E-Mail: lenz using imbi.uni-freiburg.de



More information about the R-package-devel mailing list