I understand the problem and wasn't voting either way on the S3
replacement function generic you want in stats. Prof. Ripley noted that
it's odd to have stats doing that to solve the problems of two outside
packages when it doesn't even have the function concerned, but others
may have opinions either way. It's certainly not a good precedent.
Every time a package writes an S3 generic version of a function in a
base package (or, in this case, not in a base package), should the base
package convert its function to an S3 generic? (This problem is one
reason for the S4 implicit generic idea, so that methods can be written
compatibly for existing functions.)
Your request requires writing and documenting the new function, so at
least you should provide a patch that can be inserted without adding
more work for R-core.
But that was not my main point.
The point is that such problems with name conflicts arise in many
ways--I agree that they arise especially easily when one package uses S4
and another S3 methods with the same named function. It can and does
arise anyway, e.g., the two versions of gam() noted in my book (p. 26).
The general solution is to have a namespace for your package and to
ensure that it imports only what you want. Then the results are
independent of packages attached, _provided_ the user is calling a
function from your package.
Users calling both packages from the global environment may have to be
specific as to which version they want, say by using the "::" operator.
This is a consequence (a deficiency if you like) of the classic S and R
rule of using the first version of a function encountered. It's
possible that the evaluator in the future could be more sophisticated
and recognize the situation of compatible S3 and S4 functions, but it
won't be for 2.9.0.
The addition to stats won't help unless/until zoo and any other package
with a replacement version of time() removes that function.
John
Yohan Chalabi wrote:
>>>>> "JC" == John Chambers <j...@r-project.org>
>>>>> on Wed, 11 Mar 2009 19:10:29 -0700
>>>>>
>
> JC> The problems are related to masking objects (in this case ) in
> JC> the search list, not especially related to methods.
> JC>
> JC> It was in order to get around such problems that NAMESPACE
> JC> was added to
> JC> R. You should use it, but it applies to evaluating calls
> JC> to functions
> JC> in the package, by avoiding the dependency on the order of
> JC> packages in
> JC> the search list. To ensure correct results, you need to call a
> JC> function from your package (i.e., one that is not masked). The
> JC> computations in the function will see what has been imported
> JC> into the
> JC> namespace.
> JC>
> JC> For example, if you do the following:
> JC>
> JC> 1. add a NAMESPACE file, for example containing:
> JC>
> JC> import(stats)
> JC> import(zoo)
> JC> exportPattern(^[a-zA-Z])
> JC>
> JC> 2. Do the computations in a function in your package,
> JC> say doDemo(),
> JC> with a few show(time()) lines added to print things.
> JC>
> JC> 3. With the import(zoo), no need to define as an S3 generic.
> JC>
> JC> Then things behave with or without zoo attached, because the
> JC> computations are defined by your namespace.
>
>
> Thank you for your responses.
>
> 'timeSeries' and 'zoo' both have functionality for time series
> management. Although they have similar concepts, they are intrinsically
> different; the former package uses S4 classes and the latter S3 classes.
>
> Until now both packages have been able to coexist and have been
> independent from each other.
>
> As I mentioned in my previous post, both packages define methods to
> extract timestamps of their respective classes with the function
> 'time' .
>
> I agree with you that if we had used a function name and its
> assignment version defined in 'zoo', we should import it from their
> namespace. But in this case, 'time<-' is the natural extension of a
> function already present in a base package.
>
That wasn't my point. It was only your demo that required importing
zoo into your dummy package.
> Until now we defined the S3 generic 'time<-' so that both packages
> could coexist without needing to import the function from the
> namespace of the other. But this workaround won't work anymore if we
> define an S4 generic.
>
> We are thus asking the R developers if they could add 'time<-' as a
> generic in 'stats' because it is the natural extension of an existing
> function. This will ensure that packages can continue to coexist and
> remain independent.
>
> Best regards,
> Yohan
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
