[Bioc-devel] RangedSummarizedExperiment

Hervé Pagès hpages at fredhutch.org
Fri Jun 19 02:42:40 CEST 2015


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

   (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).


> 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

More information about the Bioc-devel mailing list