R devel - Oct 2003 - Are package maintainers responsible for name-mangling class names?

The following came up when Roger Bivand and I discussed
R's name spaces and overlap in packages, in the bus to the
field trip during StatGIS, last Tuesday:

If two packages create the same class, say "variogram", and both
are loaded, then using a method for an object of class "variogram"
cannot discriminate between them and will call the method in the
package loaded last. See example below.

I know what is happening, but for average users this may be
extremely confusing, especially when loading the second package
does  not result in a warning that plot.variogram in the first
is masked (gstat uses name spaces and "exports" plot.variogram
through S3method(plot, variogram), geoR does not)

Shouldn't R know that objects created by functions in library x
prefer there methods to be picked from library x, rather than
the first in the search path? Isn't that one of the ideas behind
name spaces?

Shouldn't R give an error message when a loaded library
masks a method in another library, as it does when an object
is masked (such as it does when loading gstat after spatial)?

If we are not going to deal  with this, shouldn't CRAN
reject (for now?) packages that create new classes and
methods with names that are allready in other packages?
--
Edzer


Executing the following commands:

library(gstat)
data(meuse)
v = variogram(log(zinc)~1, ~x+y, meuse)
plot(v) # calls plot.variogram() in library gstat
library(geoR)
plot(v) # error: calls plot.variogram() in library geoR

gives the following output:

R> library(gstat)
Loading required package: lattice
Loading required package: grid

R> data(meuse)

R> v = variogram(log(zinc) ~ 1, ~x + y, meuse)

R> plot(v)

R> library(geoR)

-------------------------------------------------
geoR - functions for geostatistical data analysis
geoR version 1.3-16 (2003-09-17) is now loaded
-------------------------------------------------


R> plot(v)
Error in if (x$output.type == "bin") Ldots$type <- "p" :
        argument is of length zero
In addition: Warning message:
no finite arguments to max; returning -Inf

On Thu, 2 Oct 2003, Edzer J. Pebesma wrote:
> The following came up when Roger Bivand and I discussed
> R's name spaces and overlap in packages, in the bus to the
> field trip during StatGIS, last Tuesday:
>
> If two packages create the same class, say "variogram", and both
> are loaded, then using a method for an object of class
"variogram"
> cannot discriminate between them and will call the method in the
> package loaded last. See example below.
>
> I know what is happening, but for average users this may be
> extremely confusing, especially when loading the second package
> does  not result in a warning that plot.variogram in the first
> is masked (gstat uses name spaces and "exports" plot.variogram
> through S3method(plot, variogram), geoR does not)
>
> Shouldn't R know that objects created by functions in library x
> prefer there methods to be picked from library x, rather than
> the first in the search path? Isn't that one of the ideas behind
> name spaces?
I think this can only happen if method registration is compulsory (and if
you want S4 methods, you know where to find them).
> Shouldn't R give an error message when a loaded library
> masks a method in another library, as it does when an object
> is masked (such as it does when loading gstat after spatial)?
>
Yes.  I don't know whether this is an oversight or something that would be
nice but is too difficult.  I think it's unlikely to be fixed by next week
for 1.8.0, though.

> If we are not going to deal  with this, shouldn't CRAN
> reject (for now?) packages that create new classes and
> methods with names that are allready in other packages?
I hope not.  Note that it is probably not easy to come up with an
automated system that can distinguish a package that uses classes from other
packages from one that overrides classes from other packages.

	-thomas

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley@u.washington.edu	University of Washington, Seattle