From: Gabor Grothendieck <ggrothendieck_at_gmail.com>

Date: Fri 03 Feb 2006 - 15:54:30 EST

R-help@stat.math.ethz.ch mailing list

https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Received on Fri Feb 03 16:02:13 2006

Date: Fri 03 Feb 2006 - 15:54:30 EST

In thinking about this some more here is a slightly simpler solution than my previous one:

library(zoo)

z <- ts(1:3)

f <- function(y) {

index <- local(function(x) index(x), .GlobalEnv)
index(y)

}

environment(f) <- baseenv()

f(z)

On 2/2/06, Gabor Grothendieck <ggrothendieck@gmail.com> wrote:

> I think the issue in this case is the following aspect of UseMethod

*> from ?UseMethod:
**>
**> "'UseMethod' and 'NextMethod' search for methods in
**> two places: first in the environment in which the generic function
**> is called, and then in the registration data base for the
**> environment in which the generic is defined"
**>
**> Even if one is successful in calling a generic function such as index
**> from a function f with NULL environment UseMethod will look into
**> the environment within f (and not find it since its parent was set to
**> NULL) and since in this case the methods were not registered by the
**> package it does not find them in the package either. This could have
**> worked somewhat more smoothly had the methods been registered.
**>
**> On 2/2/06, Duncan Murdoch <murdoch@stats.uwo.ca> wrote:
**> > 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@stat.math.ethz.ch
**> > > [mailto:r-help-bounces@stat.math.ethz.ch] On Behalf Of Duncan Murdoch
**> > > Sent: Thursday, February 02, 2006 2:16 PM
**> > > To: fsaldanha@alum.mit.edu
**> > > Cc: r-help@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@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
**> > >>>>
**> > >>>> ______________________________________________
**> > >>>> R-help@stat.math.ethz.ch mailing list
**> > >>>> https://stat.ethz.ch/mailman/listinfo/r-help
**> > >>>> PLEASE do read the posting guide!
**> > > http://www.R-project.org/posting-guide.html
**> > >
**> > > ______________________________________________
**> > > R-help@stat.math.ethz.ch mailing list
**> > > https://stat.ethz.ch/mailman/listinfo/r-help
**> > > PLEASE do read the posting guide!
**> > > http://www.R-project.org/posting-guide.html
**> > >
**> > > ______________________________________________
**> > > R-help@stat.math.ethz.ch mailing list
**> > > https://stat.ethz.ch/mailman/listinfo/r-help
**> > > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
**> >
**> > ______________________________________________
**> > R-help@stat.math.ethz.ch mailing list
**> > https://stat.ethz.ch/mailman/listinfo/r-help
**> > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
**> >
**>
*

R-help@stat.math.ethz.ch mailing list

https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Received on Fri Feb 03 16:02:13 2006

*
This archive was generated by hypermail 2.1.8
: Fri 03 Mar 2006 - 03:42:21 EST
*