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
[EMAIL PROTECTED]       University of Washington, Seattle

______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

Reply via email to