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