[Bioc-devel] Biobase / eSet changes for this release
Hi Rafa, I'm going to answer out of order... Rafael A Irizarry <ririzarr at jhsph.edu> writes:
2) It seems that in general we will be storing an esimate (expression, calls, copynumber) and some kind of measure of uncertainty (SE for expression, p-value fo calls, etc..). However, a big chunk fo the apps will not use uncertainty. It would be a shame to have to store a matrix of NAs every single time. How hard would be to have eSet take NULL for some matrices? The validity check can look at everything that is not NULL. Notice that the alternative is to define a new class which means, in my case, Ill need two classes for every class Im defining or having a matrix of NAs, which, given the size of data these days, will be very inneficient.
I think we should define an EmptyMatrix class:
setClass("EmptyMatrix", contains="matrix")
Why? Because:
* new("EmptyMatrix") is small (no elements)
* We can dispatch on it. I think we might be able to get some
propagation of empty similar to how NA works. This can keep the
code from having to do lots of explicit type checking.
* NULL can happen by accident and should be an error. EmptyMatrix
won't just "appear" from a calculation.
* It will also mean that these values could go in a proper slot of
type "matrix" without having to create the matrixOrNull class
union.
1) SNPset as it is will not be useful. As far as I know only Rob and me are developing software that will use snpSet. Both of us need a slot for copynumber. Otherwise we will need to create a new class, which will be the only one used, and we wont get to use the name SnpSet.
There is something to be said for reserving the general class names for things that will be general. Perhaps it makes sense to choose a slightly more specific name while sorting out the all-purpose use cases. Your RafaSnpSet can become SnpSet. But if you start with SnpSet and go off in a direction that is not useful to others, then there is no easy fix. + seth