Re: [Rd] NAMESPACE Q: does import as exist?

From: Luke Tierney <>
Date: Wed 08 Feb 2006 - 18:11:36 GMT

We anticipated this issue when the name space mechanism was designed, and the design allows for this, but we deliberately did not formally document this at the time. As with most things like this there are trade-offs. Allowing for renaming complicates the code; it also may prevent, or at least significantly complicate, changes in the implementation we might want to make. On the other hand this might be quite useful in some settings. We had some disagrements about how useful, so the compromise was to leave the facility in but not officially document it, and wait and see what the need looks like. This is the first request I recall in almost three years since the mechanism was introduced, so it is not a major issue.

The support for renaming on import allows you to use the directive

         importFrom(bar, hh = g)

to import bar::g as hh in your package.

Since this mechanism is not officially documented and has not been used or tested, changes that have occurred in the code over time may have broken things, or things may have been added that did not take renaming into account. For example, the parallel facility for renaming on export seems to have been broken somewhere along the way. So if you want to use this do so with caution. If we see substantial usage we may need to think about formally documenting and testing this; but only after carefully considering whether it does impose limits on other things we would like to do.

Some of the throughts on this are described in, also available off the developer page



On Wed, 8 Feb 2006, Seth Falcon wrote:

> On 8 Feb 2006, wrote:
>>>> in a NAMESPACE file. Useful-- yes. Possible-- I don't know!
>>> Yes, this is along the lines of what I was thinking. An unpleasant
>>> work around would be to create a translation package
>>> that does something along the lines of Duncan M.'s suggestion,
>>> importing, renaming, exporting.
>> Why do you call it unpleasant?
> Because other languages do this without defining an extra "package".
> I don't think users should have to go to that length to resolve such
> name issues.
>> With the current mechanisms in R, that's probably what your
>> ImportFromAs function would have to do. There's no way to have two
>> names referring to the same function.
> Do you mean: there's no way to have one name referring to two
> different functions?
> After looking over some of the namespace code, I think what I'm asking
> for is possible (without creating extra packages). E.g., attaching a
> package with a NAMESPACE file looks like it will call
> attachNamespace(), which creates an empty env on the search path and
> then calls importIntoEnv() to fill it. ImportIntoEnv() ends up in
> do_importIntoEnv in envir.c. The comment there is encouraging:
> /* This function copies values of variables from one environment
> to another environment, possibly with different names.
> Promises are not forced and active bindings are preserved. */
> Am I on track here that this implies that it is possible to have an
> importFromAs directive without change to the current underlying
> mechanism and that only higher level additions would be needed (not to
> say it would be easy).
> Best,
> + seth
> ______________________________________________
> mailing list

Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:
Iowa City, IA 52242                 WWW:

______________________________________________ mailing list
Received on Thu Feb 09 07:15:28 2006

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:40 GMT