The problems are related to masking objects (in this case `time<-` ) in 
the search list, not especially related to methods.

It was in order to get around such problems that NAMESPACE was added to 
R.  You should use it, but it applies to evaluating calls to functions 
in the package,  by avoiding the dependency on the order of  packages in 
the search list.  To ensure correct results, you need to  call a 
function  from your package (i.e., one that is not masked).  The 
computations in the function will see what has been imported into the 
namespace.

For example, if you do the following:

1.  add a NAMESPACE file, for example containing:

import(stats)
import(zoo)
exportPattern("^[a-zA-Z]")

2.  Do the computations in a function in your package, say doDemo(), 
with a few show(time()) lines added to print things.

3.  With the import(zoo), no need to define `time<-` as an S3 generic.

Then things behave with or without zoo attached, because the 
computations are defined by your namespace.   Without attaching zoo:

-------
 > require(timeProb)
Loading required package: timeProb
 > doDemo()
[1] "aTest2"
Loading required package: zoo

Attaching package: 'zoo'


    The following object(s) are masked from package:timeProb :

     time<-


    The following object(s) are masked from package:base :

     as.Date.numeric

[1] "aTest3"
[1] "2003-02-01" "2003-02-03" "2003-02-07" "2003-02-09" "2003-02-14"
----------

Notice the masking of `time<-`.  Did you notice that before?







Yohan Chalabi wrote:
>>>>> "JC" == John Chambers <jmc@r-project.org>
>>>>> on Wed, 11 Mar 2009 09:57:43 -0700
>>>>>           
>
>    JC> Whatever one wants for an S3 generic, it's not needed to do what,
>    JC> presumably, you want here.
>    JC>
>    JC> And for sure it is no excuse for S3 methods for S4 classes.
>    JC>
>    JC> Back to basics: To write S4 methods for an existing function, the clean
>    JC> and simple way is usually:
>    JC>
>    JC> setGeneric("time<-")
>    JC>
>    JC> If your package depends on one that has S3  methods for this function,
>    JC> there will be a version of the function imported into your namespace.
>    JC> That function will then be the default method.
>    JC>
>    JC> Presumably you want to ensure that S3 methods, for S3 classes, are still
>    JC> dispatched.  Quite reasonable and it should follow from the call to
>    JC> setGeneric.
>    JC>
>    JC> If you wanted to have your own S3 methods or if you weren't willing to
>    JC> assume an S3 generic imported, you could do a 2-line version:
>    JC>
>    JC> R(r48103)> `time<-` <- function(x, value) UseMethod("time<-")
>    JC> R(r48103)> setGeneric("time<-")
>    JC> [1] "time<-"
>    JC> R(r48103)> showMethods("time<-", include = TRUE)
>    JC> Function: time<- (package .GlobalEnv)
>    JC> x="ANY"
>    JC> function (x, value)
>    JC> UseMethod("time<-")
>
> In my opinion you example only works in '.GlobalEnv' environement, but
> does not work when implemented in a package.
>
> I wrote a small package to illustrate the problem.
>
> ## R code
> oldDir <- getwd()
> setwd(tempdir())
>
> url <- "http://nic.phys.ethz.ch/~chalabi/timeProb_0.001.tar.gz"
> download.file(url, "timeProb_0.001.tar.gz")
> install.packages("timeProb_0.001.tar.gz", repos = NULL)
>
> # you also need to install another package which uses `time<-`.
> # for example zoo
> if(!require(zoo))
>     install.packages("zoo")
>
> # Now we quit and start a new R session
> setwd(oldDir)
> q()
>
> # new R
>
> # we first load timeProb
> library(timeProb)
>
> # and then run the demo
> demo(timeProb)
>
> # now we quit and start again a new session
> q()
>
> # new R
>
> # but now we first load zoo and after timeProb
> library(zoo)
> library(timeProb)
>
> # and run again the demo
> demo(timeProb)
>
> ## end R code
>
> As far as I understand it, two packages can not coexist if one of
> them defines an S3 generic and the other one defines an S4 generic
> with the same name.
>
> Or am I missing an option when defining the S4 generic?
>
>    JC>
>    JC> As a postscript, here is the current plan, not yet committed, pending
>    JC> some more testing:
>    JC>   - the bad methods will be allowed
>    JC>   - warnings when a class is defined with such methods for a superclass
>    JC>   - probably some other warnings, but not for an ordinary call to the
>    JC> method (it's the MISSING calls to the method that are the disaster).
>    JC>
>
> Thanks for giving more information concerning the current plan.
>
>    JC> More later,
>    JC>   John
>    JC>
>
>
> regards,
> Yohan
>
> --
> PhD student
> Swiss Federal Institute of Technology
> Zurich
>
> www.ethz.ch
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>   

	[[alternative HTML version deleted]]

