[Rd] Are package maintainers responsible for name-mangling class names?

Thomas Lumley tlumley at u.washington.edu
Thu Oct 2 07:56:46 MEST 2003

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 Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle

More information about the R-devel mailing list