hpages at fredhutch.org
Fri Jun 19 03:21:08 CEST 2015
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 ;-)
> On Thu, Jun 18, 2015 at 5:42 PM, Hervé Pagès <hpages at fredhutch.org
> <mailto:hpages at fredhutch.org>> wrote:
> On 06/18/2015 10:48 AM, Elena Grassi wrote:
> Hi Hervé,
> thanks for your kind answer - refactoring is always good, I've
> 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
> 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
> 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
> simply having another slot to avoid such initializations
> Not sure I understand what you're asking exactly. Can you
> more details?
> That wasn't a very clear question also in my mind, sorry...it
> from my not so deep understanding of S4 inheritance mechanism, I
> to patch it today :)
> Basically I was wondering if extending classes and thus maybe
> tinkering with their inner mechanisms more than when simply
> 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,
> 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
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