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:> 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
>
> --
> Timothy H. Keitt
> Department of Ecology and Evolution
> State University of New York at Stony Brook
> Stony Brook, New York 11794 USA
> Phone: 631-632-1101, FAX: 631-632-7626
> http://life.bio.sunysb.edu/ee/keitt/
>
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read
http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
>
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
--
Luke Tierney
University of Minnesota Phone: 612-625-7843
School of Statistics Fax: 612-624-8868
313 Ford Hall, 224 Church St. S.E. email: luke@stat.umn.edu
Minneapolis, MN 55455 USA WWW: http://www.stat.umn.edu
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._