From jmc@research.bell-labs.com  Fri Jun 28 13:21:33 2002
From: jmc@research.bell-labs.com (John Chambers)
Date: Fri, 28 Jun 2002 08:21:33 -0400
Subject: (PR#1715) Re: package `methods' has persistent effects even
 ifdetached
References: <200206280551.HAA06028@pubhealth.ku.dk>
 <Pine.GSO.4.44.0206280919500.23166-100000@auk.stats>
 <15644.10672.168515.693504@mithrandir.hornik.net>
 <15644.13106.766528.617696@gargle.gargle.HOWL> <15644.14379.430320.396271@mithrandir.hornik.net>
Message-ID: <3D1C54CD.33E9D5D2@research.bell-labs.com>

Kurt Hornik wrote:
....................................................
> 
> The culprit is
> 
>     for(i in rev(seq(along = search())))
>       cacheMetaData(as.environment(i), TRUE)
>     if (! identical(environment(log), .GlobalEnv)) { # check if namespace used
>         # if base is using a name space then any replacements for functions
>         # in base defined in methods need to be installed directly into base
>         # or they will not be visible to base code.
>         for (n in ls(env = where))
>             if (exists(n, env = NULL))
>                 assign(n, get(n, env = where), env = NULL)
>     }
> 
> in .First.lib() of methods.
> 
> There is a general issue here: base should conceptually be considered as
> sealed.  If we really need to unlock the bindings when attaching methods
> then we should restore the original ones when detaching but it does not
> feel right to do this at all.  Luke will have more to say, I am sure.
> 
> -k
> 
> > Martin

Yes, definitely a general question here.  And it's related to Martin's
earlier report about all.equal.

As I mentioned, the inconsistency there resulted from data.class (in
base) behaving differently when the methods package was attached, with
its different version of class.


Intuitively, the code added to .First.lib seems to contradict the
namespace idea.  The issue may be whether any code in base breaks if it
continues to use the base version of class() when the methods package is
attached.  Luke will know better, but my feeling is that we should fix
any problems of that sort directly, and undo the change to .First.lib.

(There are some other redefinitions in methods, including plot with a
"y" argument.  But it's class and class<- that seem likely to be used by
other code in base.)

John

-- 
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


(PR#1715) Re: package `methods' has persistent effects even ifdetached
John Chambers