From tlumley at u.washington.edu  Thu Oct  2 07:56:46 2003
From: tlumley at u.washington.edu (Thomas Lumley)
Date: Thu Oct  2 15:56:19 2003
Subject: [Rd] Are package maintainers responsible for name-mangling class
	names?
In-Reply-To: <3F7C10CF.6010406@geog.uu.nl>
References: <3F7C10CF.6010406@geog.uu.nl>
Message-ID: <Pine.A41.4.58.0310020648540.71930@homer08.u.washington.edu>

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


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