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

[Duncan Murdoch]

On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:
> 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()

I wouldn't use it that way.  I'd write it as

     sjp <- juliaUsing("SomeJuliaPackage")
     sjp$myJuliaFunction()

This is similar to the advice to use pkg::foo() rather than library(pkg) 
followed by plain foo() in the code.

Duncan Murdoch

> 
> 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
>>
> 
>