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 <hpa...@fredhutch.org
<mailto:hpa...@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: hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>
Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
_______________________________________________
Bioc-devel@r-project.org <mailto:Bioc-devel@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: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
