On 2/8/2006 10:18 AM, 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.
I don't see a need for an additional package here -- it could all be done in the package doing the importing. > >> 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? No, but that's true too, if you're talking within an environment. It's certainly possible to use the same name in different environments to refer to different things. What I meant was that I can't define "foo" to refer to function "bar". I can make a copy of "bar", but not a reference. Duncan Murdoch > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
