How to get the namespace of a function?

On 2/2/2006 5:56 PM, Berton Gunter wrote:

Just echoing and slightly amplifying Gabor's comment...

The semantics of R are really based on functional programming (LISP-like)
rather than OOP (JAVA-like)? R's behavior is "proper" from that point of
view; what is "improper" is Fernando's expectation that it should behave
some other way.

I don't think it's that so much as trying not to break old code.  It
doesn't make sense to me that the search order within a namespace should
pass through the global environment, but something would break if it
didn't.  (I suspect it's probably the old S3 object system, which
predates namespaces by a long time, but it's been a while since I've
thought about this.)

Duncan Murdoch

 > Of course, one can simulate anything with a Turing machine,
but I consider Fernando's criticisms somewhat "unfair" because he is
expecting R to behave like something he is familiar with rather than as it
was designed to. For this reason, what bothers him seems wholly desirable to
me -- I want there to be well-defined scoping convention (lexical scoping)
for R to find free variables.

Cheers,

Bert



-----Original Message-----
From: r-help-bounces at stat.math.ethz.ch
[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Duncan Murdoch
Sent: Thursday, February 02, 2006 2:16 PM
To: fsaldanha at alum.mit.edu
Cc: r-help at stat.math.ethz.ch
Subject: Re: [R] How to get the namespace of a function?

On 2/2/2006 5:05 PM, Fernando Saldanha wrote:

I am trying to imitate "encapsulation" from other languages like Java
or C++. Coming from that background, it bothers me that I can commit
errors like the following:

x <- 1
f <- function(z) { y <- x; y + 1 } # Mistake: I should have written y <-

z

f(10)

[1] 2

In a language like Java the interpreter would have noticed that x was
an undeclared variable and an error message would be issued. R, on the
other hand, allows the code to run, as x exists in the global
environment. I was trying to avoid such situations by  setting the
environment of f to be NULL. If there is a better way to catch this
type of errors I would be interested in knowing about it.

Put your code in a package, and use a namespace.  This isn't perfect,
but it gives you more control than you have when running scripts at the
console.

There's an article by Luke Tierney in one of R News 3/1 that explains
the search order when namespaces are involved.

Duncan Murdoch

FS

On 2/2/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

On 2/2/2006 10:56 AM, Fernando Saldanha wrote:

I declared the environment of the function myfun to be NULL as follows:

environment(myfun) <- NULL

Since version 2.1.0, it's been recommended that you use

environment(myfun) <- baseenv()

and since 2.2.0, you'll get a warning when using NULL (and you'll get an
error in 2.3.0).  But why would you want to do that?  What are you
trying to achieve?

Duncan Murdoch

Later on I called that myfun and got an error message because the
function index() in the zoo package was called inside myfun and was
not visible:

Error in myfun(args) : couldn't find function "index"

I tried to use zoo::index() instead of index(), but that did not work.
In fact, zoo::index does not work even in the command line:

z<-ts(1:5)
z

Time Series:
Start = 1
End = 5
Frequency = 1
[1] 1 2 3 4 5

index(z)

[1] 1 2 3 4 5

zoo::index(z)

Error in loadNamespace(name) : package 'zoo' does not have a name space

How can I qualify index() so that it is visible inside the body of

myfun?

Thanks for any suggestions,

FS