[Rd] NAMESPACE Q: does import as exist?

[Duncan Murdoch]

On 2/8/2006 10:18 AM, 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.

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel