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, [EMAIL PROTECTED] 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@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: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel