From dwinsemius at comcast.net  Sat Feb 23 03:50:07 2013
From: dwinsemius at comcast.net (David Winsemius)
Date: Fri, 22 Feb 2013 18:50:07 -0800
Subject: [Rd] Recommended way to call/import functions from a Suggested
	package
In-Reply-To: <AD286524-32D5-4808-B984-E6AF521FB6E5@comcast.net>
References: <FD2C7845-F6AD-4AA1-91C1-8CB14F43AA7D@stat.ubc.ca>
	<CABdHhvHkJkyzKODdDKKt+fmCeUAXJC7L24vXLuLPWmRYsYZtkQ@mail.gmail.com>
	<AD286524-32D5-4808-B984-E6AF521FB6E5@comcast.net>
Message-ID: <3134DCA3-4BFA-4D0F-8BDD-A7A185FDF8C8@comcast.net>


On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:

> 
> On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
> 
>> Hi Davor,
>> 
>> To the best of my knowledge, there's only one way to use functions
>> from a suggested package: with require:
>> 
>> if (require("suggested_package")) {
>> function_from_suggested_package()
>> } else {
>> stop("suggested package not installed")
>> }
>> 
>> Unfortunately I don't think there's any way to use a suggested package
>> without polluting the search path.
> 
> I've always wondered: How does lattice manage to use grid functions without putting them on the search path?

Maybe I am using the wrong terminology, so here is the behavior I'm referring to:

> sessionInfo()
snipped version an locale ino

attached base packages:
[1] grDevices datasets  splines   graphics  utils     stats     methods   base     

other attached packages:
[1] rms_3.6-2       Hmisc_3.10-1    survival_2.37-2 sos_1.3-5       brew_1.0-6     
[6] lattice_0.20-10

loaded via a namespace (and not attached):
[1] cluster_1.14.3 grid_2.15.2   

Notice that lattice is loaded from my profile

> require(ggplot2)
Loading required package: ggplot2
> sessionInfo()
.... snipped version an locale ino
attached base packages:
[1] grDevices datasets  splines   graphics  utils     stats     methods   base     

other attached packages:
[1] ggplot2_0.9.3   rms_3.6-2       Hmisc_3.10-1    survival_2.37-2 sos_1.3-5      
[6] brew_1.0-6      lattice_0.20-10

loaded via a namespace (and not attached):
 [1] cluster_1.14.3     colorspace_1.2-1   dichromat_2.0-0    digest_0.6.0      
 [5] grid_2.15.2        gtable_0.1.2       labeling_0.1       MASS_7.3-22       
 [9] munsell_0.4        plyr_1.8           proto_0.3-10       RColorBrewer_1.0-5
[13] reshape2_1.2.2     scales_0.2.3       stringr_0.6.2     
> ?grid.text
No documentation for ?grid.text? in specified packages and libraries:
you could try ???grid.text?

So at least the help system cannot find a grid function.


> ?grid::grid.text
starting httpd help server ... done
> grid.text
Error: object 'grid.text' not found

Neither can the R interpreter find it. But it's clearly available if you ask nicely:

> grid::grid.text
function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"), 
    just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap = FALSE, 
    default.units = "npc", name = NULL, gp = gpar(), draw = TRUE, 
    vp = NULL) 
{
    tg <- textGrob(label = label, x = x, y = y, just = just, 
        hjust = hjust, vjust = vjust, rot = rot, check.overlap = check.overlap, 
        default.units = default.units, name = name, gp = gp, 
        vp = vp)
    if (draw) 
        grid.draw(tg)
    invisible(tg)
}
<bytecode: 0x11617dd50>
<environment: namespace:grid>

-- 
David/

> 
> -- 
> David
>> 
>> Hadley
>> 
>> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic <cubranic at stat.ubc.ca> wrote:
>>> If in my package "Foo" I call a function from another package "Bar" if it's available, according to R-exts, this sounds like I should include "Suggests: Bar" in package Foo's description. But the manual is silent on how to treat Bar's namespace. Should I import it? If so, should this be conditional or unconditional? There is a thread from 2008 in which Duncan Murdoch suggests trying conditionally importing a package if it's installed, with the caveat "If this is allowed" (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears to work in current release of R, 2.15.2, but I'm still not clear if it's officially allowed, much less recommended.
>>> 
>>> The manual also says:
>>> 
>>>> If a package only needs a few objects from another package it can use a fully qualified variable reference in the code instead of a formal import. A fully qualified reference to the function f in package foo is of the form foo::f. This is slightly less efficient than a formal import and also loses the advantage of recording all dependencies in the NAMESPACE file, so this approach is usually not recommended. Evaluating foo::f will cause package foo to be loaded, but not attached, if it was not loaded already?this can be an advantage in delaying the loading of a rarely used package.
>>>> 
>>> 
>>> 
>>> Would this be a better solution than importing when calling into a suggested package?
>>> 
>>> Davor
>>> 
>>> 
>>>       [[alternative HTML version deleted]]
>>> 
>>> 
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 
>> 
>> 
>> -- 
>> Chief Scientist, RStudio
>> http://had.co.nz/
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> David Winsemius
> Alameda, CA, USA
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

David Winsemius
Alameda, CA, USA



[Rd] Recommended way to call/import functions from a Suggested package
David Winsemius