Hi David: According to the description on cran, lattice imports grid.
I don't know if you've seen it but www.obeautifulcode.com has a very nice
topic in its archives called "How R Searches and Finds Stuff" which is
relatde to your question that I found it to be really helpful. A lot of
people on this list ( you know who they are as well as I do ) know it all
in their heads but, for me, sitting down and reading it was truly
enlightening. I think it should be required reading for anyone starting out
with R.
On Fri, Feb 22, 2013 at 9:50 PM, David Winsemius <dwinsem...@comcast.net>wrote:
>
> 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 <cubra...@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
> alreadythis 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@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >>
> >>
> >> --
> >> Chief Scientist, RStudio
> >> http://had.co.nz/
> >>
> >> ______________________________________________
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > David Winsemius
> > Alameda, CA, USA
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> David Winsemius
> Alameda, CA, USA
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
