[Rd] NAMESPACE Q: does import as exist?

[Luke Tierney]

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
http://www.stat.uiowa.edu/~luke/R/namespaces/morenames.html, also
available off the developer page developer.r-project.org.

Best,

luke




On Wed, 8 Feb 2006, Seth Falcon wrote:

> On  8 Feb 2006, murdoch at stats.uwo.ca 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
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:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu