[Bioc-devel] RangedSummarizedExperiment

[Tim Triche, Jr.]

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
>

	[[alternative HTML version deleted]]