Skip to content

name spaces?

2 messages · Tim Keitt, Luke Tierney

Original
Tim Keitt
# 
I'm revisiting the R/S DBI package and was wondering if there is any
plan to implement package name spaces in R/S. I've taken to the habit of
prepending a few characters to function names in packages to avoid
collisions, e.g., dbConnect(). An alternative would be DBI::connect()
(s/::/preferred/) which in some ways I find more pleasing. Not having
thought about it in detail, it seems pretty simple, except for backward
compatibility. Packages already load function defs into their own
environment. Keeping the name space seperate means simply not adding
that environment to the search path and using the package name as an
index into a name space lookup table, i.e., connect() looks in global
and DBI::connect() looks in the DBI package environment. One could then
have a use(DBI::connect) function that loads 'connect' into the global
name space, and a global option 'use.name.spaces' or something to change
the default behavior. (An alternate approach would be to use
DBI.connect() and add a switch to 'library' or global option that strips
off the 'DBI' prefix.) Anyway, it would help in nailing down the DBI
interface to know if some name space mechanism is in the works.

Cheers,
Tim
2 days later
Luke Tierney
# 
This is in the works and will hopefully make it into 1.5 or, more
likely at this point, 1.6.  A preliminary version is available at
http://www.stat.umn.edu/~luke/R/namespaces/morenames.html or off
the developer page http://developer.r-project.org.

We do not yet have a syntactic mechanism like DBI::connect for
referring to an exported variable from a package without explicitly
importing the variable, but we will probably add something along those
lines.

One change that is likely to happen as part of introducing name spaces
is that functions defined in base package will have .BaseNamespaceEnv
as their environment rather than .GlobalEnv.  Evaluating in this
environment means base is searched before the global environment and
attached packages.  As a result, variable assignments in loaded
packages and at top level will no longer shadow variables used within
the definition of base functions.  This will eliminate certain errors
of accidentally redefining things like pi that come up occasionally,
but will also make deliberate redefinition of functions in base harder
(not impossible, just harder).

In principle implementing name spaces is just a matter of using
environments as you describe, but there are a few complications.  One
is that with importing from one name space into another a variable can
in some sense exist in two environments at the same time, and what
this means needs to be resolved.  I've chosen the easy way out of
making variables in name spaces read-only (which is useful for other
reasons as well).  Another issue is that in R a closure can capture a
reference to a name space which can then be stored in a .Rdata file.
Making sure that sensible things happen when storing (_not_ writing
out the contents of the entire name space) and loading (attempting to
locate and load the right name space) makes things a bit tricky and
forces some compromises, but I think this is all mostly resolved.

luke
On Fri, Mar 22, 2002 at 10:55:11AM -0500, Timothy H. Keitt wrote: