Skip to content

On implementing zero-overhead code reuse

8 messages · Kynn Jones, frederik at ofb.net, Dirk Eddelbuettel +2 more

Original
Kynn Jones
# 
I'm looking for a way to approximate the "zero-overhead" model of code
reuse available in languages like Python, Perl, etc.

I've described this idea in more detail, and the motivation for this
question in an earlier post to R-help
(https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html).

(One of the responses I got advised that I post my question here instead.)

The best I have so far is to configure my PROJ_R_LIB environment
variable to point to the directory with my shared code, and put a
function like the following in my .Rprofile file:

    import <- function(name){
        ## usage:
        ## import("foo")
        ## foo$bar()
        path <- file.path(Sys.getenv("PROJ_R_LIB"),paste0(name,".R"))
        if(!file.exists(path)) stop('file "',path,'" does not exist')
        mod <- new.env()
        source(path,local=mod)
        list2env(setNames(list(mod),list(name)),envir=parent.frame())
        invisible()
    }

(NB: the idea above is an elaboration of the one I showed in my first post.)

But this is very much of an R noob's solution.  I figure there may
already be more solid ways to achieve "zero-overhead" code reuse.

I would appreciate any suggestions/critiques/pointers/comments.

TIA!

kj
frederik at ofb.net
# 
Hi Kynn,

Do you mind defining the term "zero-overhead model of code reuse"?

I think I understand what you're getting at, but not sure.

Thank you,

Frederick
On Sun, Oct 02, 2016 at 01:29:52PM -0400, Kynn Jones wrote:
Kynn Jones
# 
Hi Frederick,

I described what I meant in the post I sent to R-help
(https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html),
but in brief, by "zero overhead" I mean that the only thing needed for
library code to be accessible to client code is for it to be located
in designed directory.  No additional meta-files, packaging/compiling,
etc. are required.

Best,

G.
On Sun, Oct 2, 2016 at 7:09 PM, <frederik at ofb.net> wrote:
Kynn Jones
#
On Sun, Oct 2, 2016 at 8:01 PM, Kynn Jones <kynnjo at gmail.com> wrote:
^^^^^^^^

Sorry, I meant to write "designated".
Dirk Eddelbuettel
# 
Kynn,

How much homework have you done researching any other "alternatives" to the
package system?  I know of at least one...

In short, just about everybody here believes in packages. And repositories.
And package management.  And version control (at the package level). And
maybe byte compilation.  And associated documentation.  And unit tests.  And
continuous integration.

You don't have to -- that's cool.  Different strokes for different folks.

But if think you need something different you may just have to build that
yourself.

Cheers, Dirk
Gabor Grothendieck
# 
Have a look at the CRAN modules package and the import package.
On Sun, Oct 2, 2016 at 1:29 PM, Kynn Jones <kynnjo at gmail.com> wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Konrad Rudolph
    

    

      
      #
    

  


  

      
Check out ?klmr/modules? on Github (distinct from CRAN?s ?modules?!). It
looks pretty much exactly like what you want:

https://github.com/klmr/modules

It has an extensive README and vignette explaining the usage.

Cheers,
Konrad

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Kynn Jones
    

    

      
      #
    

  


  

      
@Konrad, you're right, that's exactly what I'm looking for.  That's
great stuff.  Thanks!  (And thanks also to Gabor Grothendieck, who
suggested modules to me way back.)


On Tue, Oct 4, 2016 at 7:07 AM, Konrad Rudolph

        
<konrad.rudolph+r-devel at gmail.com> wrote: