Are package maintainers responsible for name-mangling class names?
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