Skip to content
Prev 10462 / 63424 Next

namespaces and S4 methods/classes

Ross Ihaka wrote:
Yes.  The intent is that if you create f and methods for it, then EITHER
export(f) OR exportMethods(f) will export the generic and its methods. 
If f was a generic in another package, exportMethods(f) will just export
the methods defined in this package (that's the current model, but there
are some questions about what one really wants to do).
Currently, it's all or nothing:  Either you export the generic and its
methods or neither.

There are a couple of reasons.  First, the export/import information is
in the NAMESPACE file only, separate from the package source; so, the
mechanism is to evaluate all the package source and then export the
named objects.  Second, because only object names are used, there is
currently no mechanism to export a partial definition of the generic
(which is probably the way to think of the generic-only export:  Export
the generic as it's defined after the setGeneric() call but before some
setMethod() calls).

It's fairly likely the mechanism will be extended.  For one thing, it
seems necessary eventually to exclude methods that have private classes
in their signature.  Otherwise the exported generic has methods for
classes that are undefined.

For example, suppose "a" is an exported class and "b" a private class in
the same package and both have methods for "[":
  setClass("a", ....)
  setMethod("[", "a", .....)
  setClass("b", ....)
  setMethod("[", "b", .....)

To export the full definition of class "a" one needs exportMethods("[")
in the NAMESPACE file.  But at the moment, this exports the method for
"b" as well.

Fixing such problems may be related to allowing export() to be
associated with source code rather than with explicit objects, as
mentioned earlier.  In the above example, the first two lines would be
in an export() but the other two lines would not.  (There are some
implementation questions here, of course.)

John