[Bioc-devel] RangedSummarizedExperiment
Let the record show that it was relatively trivial to add a generic function called update() to fix the broken serialized instances of the older SE-descendant classes that now inherit from RSE... Although it was a drag until I got around to writing those. I'll try to put together a decently sized example that illustrates why I often want accordion-style mapping of things like, say, repeat exemplars back to the genome. We often keep summed counts (hey, they're repeats!) and test on those, but after determining whether a class of repeats or lncRNAs or whatever happen to be differentially transcribed/accessible/whatever, it's often useful to go back and see whether specific examples are indeed proximal to each other (either genomically, physically, or both). A picture and code will go a long way, so I'll send them when I have them. Best, --t
On Thu, Jun 18, 2015 at 5:42 PM, Herv? Pag?s <hpages at fredhutch.org> wrote:
Elena, On 06/18/2015 10:48 AM, Elena Grassi wrote:
Hi Herv?, thanks for your kind answer - refactoring is always good, I've lagged behind in the last months not following the novelties so to be truthful it has been my fault and today I was in a bit of a hurry for other reasons. I'm in the process of re-serializing
RangedSummarizedExperiment objects and fixing the packages affected by these changes (should be done before the end of the week).
Yup, I see. roar should be fixed now even if I'm not sure that the solution is satisfying in the long run, maybe after the bulk refactoring of SummarizedExperiment comes to an end I will reconsider some refactoring too :) Thanks for the explanations they cleared my head around some issues! - it would be better to avoid extending such a class and instead
simply having another slot to avoid such initializations issues?
Not sure I understand what you're asking exactly. Can you provide more details?
That wasn't a very clear question also in my mind, sorry...it derived from my not so deep understanding of S4 inheritance mechanism, I tried to patch it today :) Basically I was wondering if extending classes and thus maybe tinkering with their inner mechanisms more than when simply composing would be considered a better practice in Bioconductor where the API are not always stable but looking around in the codebase convinced me that it it's not the case.
It requires some discipline but the S4 class system actually allows one
developer to extend a class owned by another developer in a way that
remains agnostic of the internals of the parent class. This is possible
thanks to the following features (let's say B extends A):
(1) The developer of B only needs to specify B-specific slots in
setClass("B", ...)
(2) The developer of B can do:
a <- A(...) # high-level user-friendly A constructor
new("B", a, Bslot1=stuff1, Bslot2=stuff2, etc)
to create B objects (e.g. when implementing the high-level
user-friendly B constructor).
(3) The validity method for B only needs to take care of what's
new in B with respect to A, that is, of the aspects of B
objects that are not already covered by the validity method
for A objects. This is because calling validObject() on a B
object automatically validates B as an A object and then calls
the validity method for B to validate what's new in B.
In other words, validation works incrementally starting from
the root of the class hierarchy and going in the parent-to-child
direction.
(4) Like any user of A objects, the developer of B should always
use the accessors provided by the developer of A to access A
objects and the A-specific components of his/her own B objects.
Proper use of these features by developer of B leads to a clean design
where the implementation of B is not affected by changes in the
internals of A.
I was actually pleased to find out that after the recent changes in
the internals of RangedSummarizedExperiment, most of the packages
that extend this class kept working as if nothing happened. Most
failures are actually due to serialized RangedSummarizedExperiment
or derived objects that need to be updated and re-serialized
(unfortunately, changes in the internal representation of class A
always break serialized A and B objects, no matter what).
Cheers,
H.
Thanks again, E.
-- Herv? Pag?s Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel