[Bioc-devel] RangedSummarizedExperiment

[Hervé Pagès]

On 06/18/2015 05:53 PM, Tim Triche, Jr. wrote:
> 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.

No need to write anything or to add a new update() generic. Just call
updateObject() on your old SE or SE-descendant object.

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

Sounds good. Just to clarify, and at the risk of repeating myself,
my SummarizedExperiment-related mission will probably end soon when
the 2 objectives of the mission are accomplished:

   (1) Move SummarizedExperiment to its own dedicated package [DONE]

   (2) Implement degraded version of SummarizedExperiment [ALMOST DONE]

Still need to fix a few packages, re-serialize a bunch of old
serialized SE hiding in data-experiment packages, document
SummarizedExperiment0, and I'll be ready for extraction. I'll leave
to others the important follow-up mission of enhancing the new RSE
(which, again, is currently functionally equivalent to good old SE)
and adding a vignette to the new SummarizedExperiment package ;-)

Cheers,
H.

>
> Best,
>
> --t
>
>
> On Thu, Jun 18, 2015 at 5:42 PM, Hervé Pagès <hpages at fredhutch.org
> <mailto: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 <mailto:hpages at fredhutch.org>
>     Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
>     Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
>
>     _______________________________________________
>     Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org> mailing list
>     https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

-- 
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