Hi guys,

An issue has come up since the move of many generic functions to
BiocGenerics.

Often, a package will implicitly import a generic, along with any methods,
from a package using importMethodsFrom(). That of course only works if the
package in question exports the generic. This can happen implicitly via
exportMethods() (if the package defines the generic) or explicitly via
export(). If the package is using exportMethods(), then it will stop
exporting the generic when the generic is pushed up the package stack. To
be defensive, the importing package could importFrom() the generic, which
would then give an error if the package has been moved. Otherwise, R will
not throw a warning if methods are imported, but not the generic (it
probably should, right?).

So the question is whether the burden should be on the exporter (to export
the generic explicitly) or the importer (to import the generic explicitly).
In my opinion, it should be on the exporter, because then the importer
never needs to change the NAMESPACE when things move around. Also, each
exporter probably has multiple importers (dependencies). Really, the
exporter only needs to export() the generic to also export the methods, but
as the R docs say, it may be cleaner to also have exportMethods() when
methods are defined on the generic.

The case could be made that this is a problem with R. The exportMethods()
directive should always export the generic, even if the generic is defined
in another package, i.e., the chaining happens automatically.

Here is an example:

IRanges defined the unique() generic and exported it via exportMethods(),
but it was moved to BiocGenerics. Now IRanges no longer exports the
unique() generic, so a package like rtracklayer that has
importMethodsFrom(IRanges, unique) will not get the generic and code
breaks. To fix this, either rtracklayer needs to importFrom(BiocGenerics,
unique) or IRanges needs to export(unique). Which one should happen?

The workspace has not been affected by this, since IRanges has BiocGenerics
in Depends.

Michael

	[[alternative HTML version deleted]]

