Skip to content
Prev 8011 / 21307 Next

[Bioc-devel] Proper way of documenting a BiocGenerics generics with extended prototypes

On 09/21/2015 02:06 AM, Christian Arnold wrote:
Defining generics and methods instead of ordinary functions for
the getters/extractors/setters of an S4 object is generally considered
good practice. If you need to introduce new generics for that (because
the existing vocabulary doesn't suit your needs), it's recommended that
you keep their signatures as "generic" as possible e.g.

     setGeneric("parameters",
         function(object, ...) standardGeneric("object")
     )

so methods can add arguments that are specific to the objects they deal
with.

There are exceptions to this though:

For example the organism() generic that we added recently to
BiocGenerics doesn't have the ellipsis. The contract is simple: it's
a straightforward getter and we kind of want to enforce this i.e. we'd
like methods to stick to that very simple contract. If someone comes up
with a use-case where s/he needs extra arguments in the method that
operates on his/her objects, and makes a good case for it, then we can
always add the ellipsis to the generic.

Another exception can be made when it seems to make sense to have some
extra arguments like a modifier and/or a toggle added to the generic
itself. In that case, it's highly recommended to set dispatch on the
'object' argument only

     setGeneric("enrichment", signature="object",
         function(object, method="auto", ...)
             standardGeneric("enrichment")
     )

otherwise dispatch will be on all the arguments that precede the
ellipsis. Note that defining sensible default values (e.g.
method="auto" or verbose=FALSE) for these extra arguments is probably
a good idea (it's user-friendly and encourages consistent behavior
across methods).

It's all about trying to identify/anticipate what's the greatest common
factor across methods should/will be and have it formalized at the level
of the generic itself. Not necessarily an easy task though. In doubt,
better underestimate than overestimate.

H.