Just a quick note because (perhaps embarassingly) I didn't know this for a
long time:
pkg::fun() will call function fun from the namespace of package pkg
*without loading it onto the search path*
> fastdigest::fastdigest("hi there")
[1] "6fed537931bd23b42d3046c4d80790a1"
> search()
[1] ".GlobalEnv" "package:stats" "package:graphics"
[4] "package:grDevices" "package:utils" "package:datasets"
[7] "package:methods" "Autoloads" "package:base"
> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] fastdigest_0.5-0
So packages, especially with a depenency hierarchy, can get users a pretty
far way towards what you're describing.
I do think the nested namespace stuff is pretty interesting though. Looks
like there could be some fun stuff there.
~G
On Tue, Apr 29, 2014 at 6:11 AM, Barry Rowlingson <
b.rowling...@lancaster.ac.uk> wrote:
> On Mon, Apr 28, 2014 at 2:55 PM, Konrad Rudolph <
> konrad.rudolph+r-de...@gmail.com> wrote:
>
> >
> > So this is my question: what do other people think? Which is the most
> > useful and least confusing alternative from the usersâ perspective?
> >
>
> The most useful is alternative is "write packages".
>
> The overhead is minimal (install devtools, create("foo"); repeat {
> load_all("foo") ; edit; until_bugs==0} ). Reloading a package is a
> one-liner, you can't get more minimal.
>
> And with that you get a structure for documentation, a metadata standard,
> a wide range of sanity checks, and the option to push to CRAN or github for
> distribution. What you don't get is hierarchies.
>
> Can we get a hierarchy into base packages? That's the real question, and
> if answered I think it makes your module package redundant. I'd love to see
> a hierarchy with a colon-separator or something, so if I have a package
> with foo/R/thing.R and foo/R/this/thing.R I can do:
>
> require(foo)
> thing()
> this:thing()
>
> or similar....
>
> I do like your approach of returning an object that provides an access to
> the functions without side-effects, but the masses are so brainwashed into
> thinking that require(foo) can put an unknown number of unknown-named
> functions into your search list that I don't think it will ever get into
> base R...
>
> Note I did once write a simple file loader to avoid using source - it used
> sys.source to load files into an environment on the search path, storing
> the folder name so that it could be easily reloaded, but then devtools came
> along...
>
> If you want your module package to succeed you are going to have to
> duplicate all the good stuff in packages - documentation, metadata,
> distribution (trivial: zip/unzip/pull/push), and then another problem -
> people will grow out of it - they'll start writing C and Fortran code.
> Going to support that? devtools already does.
>
>
> Barry
>
> [[alternative HTML version deleted]]
>
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
