Hi,
Defining S3 methods for our data types is obviously useful, because it
helps them work with code that only sees the S3 generic. We should
encourage the definition of S3 methods whenever there is an existing
generic. Given that, some questions:
Is it still worth it to define the corresponding S4 method? Now that S3
dispatch accounts for S4 inheritance, I'm not sure there is a functional
difference. Obviously, it would be nice if there were one interface for
discovering methods. Right now, we're split between
selectMethod()/showMethods() and methods().
In particular, there are many setAs() calls where "to" is an S3 class. For
many of the basic classes, the methods package already defines a coerce
method that delegates to the as.X S3 generic. So those definitions are
redundant. For example:
> showMethods(coerce, classes="list")
Function: coerce (package methods)
from="ANY", to="list"
from="CompressedAtomicList", to="list"
from="Hits", to="list"
from="List", to="list"
from="Rle", to="list"
Those four methods are unneeded if there is an as.list method. I've noticed
that there is no coerce,ANY,data.frame so perhaps that could be added to
BiocGenerics or requested of the methods package?
Finally, the "c" function. There's no need for an S3 method here, since "c"
is a primitive. But there are notes in IRanges-class.R about how the S4
generic for "c" does not correctly account for inheritance when the
arguments are named. This is probably a bug in the methods package. But it
does seem that the S3 generic for 'c' correctly dispatches (on its first
argument) regardless of whether the arguments are named. The only downside
is that it does not enforce that all arguments in '...' are of the same
type.
Michael
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
