Skip to content
Prev 9151 / 21312 Next

[Bioc-devel] avoiding clashes of different S4 methods with the same generic

Hi,

I would not discard defining a SummarizedExperiment subclass so quickly.
SummarizedExperiment is very generic and can contain any kind of data.
IIUC the csaw package uses SummarizedExperiment to store a particular
kind of data (ChIP-seq data) and I believe specialization is a
legitimate situation for defining a subclass, even if the subclass is
a "straight" subclass i.e. a subclass that doesn't add new slots or
doesn't touch the existing slots.

OTOH introducing a "straight" subclass only to define one specialized
method on it (the "normalize" method in this case) might not be worth
it since there is a cost for such class, even if that cost is minimal:
a cost for the user (one new container/constructor to deal with) and a
cost for the developer (e.g. multiplication of coerce methods).

Changing the signature of the normalize() generic in BiocGenerics and
introducing dual dispath is of course doable but that means the
maintainers of the packages that define methods on this generic are
ok with the dual dispatch game and are willing to make the required
modifications to their packages. It's an important change and I don't
see an easy way to make it happen smoothly (i.e. thru a
deprecated/defunct cycle).

Here is the list of packages that currently define methods for
BiocGenerics::normalize():

   affyPLM
   Cardinal
   codelink
   CopyNumber450k
   csaw
   diffHic
   EBImage
   epigenomix
   MSnbase
   oligo
   qpcrNorm
   scran

[Interestingly the scran package defines a default "normalize" method
(i.e. a normalize,ANY method)].

Whether we make the second argument lightweight or parameterized (which
is something that would need to be decided at the level of the generic)
these packages will break as soon as we change the signature of the
generic. So we'll need to wait after the release before this happens.

Personally I find the lightweight second argument not particularly
intuitive, elegant, or user-friendly. I'd rather type
normalizeSwing(se, ...) or normalize(se, SwingParam(...)) than
normalize(se, WithSwing(), ...).

Last thing: In case of a parameterized second argument, do we really
need a virtual normalizeParam class as parent of all the concrete
normalizeParam* classes? If so then I guess we would need to have it
defined in BiocGenerics but I think we should try hard to not start
defining classes in this package (that could take us too far...)

H.
On 04/26/2016 03:03 PM, Aaron Lun wrote: