Well. I have two responses to that.
First, I think it would be a lot better/easier for users if (most)
developers could make use of the same plot function for "basic" classes
like PCA.
Second, if you think the basic PCA plotting routine needs enhancements,
you still have two options. On the o
Ah, I see now. Personally, I don't think Bioconductor developers should
have to agree on single plotting functions for basic classes like 'PCA'
(because this logic applies equally to the situation of all Bioconductor
developers agreeing on single MA-plot, a single variance-mean plot, etc). I
think
Hi Leo,
On 10/18/2014 10:50 AM, Leonardo Collado Torres wrote:
Hi,
A collaborator of mine is working on a new software and we while we were
doing a sanity check to compare the base-level coverage from BAM files
and bigWig files generated from his software we realized that by default
bases corre
Hi,
I don't see how it needs more functions (as long as you can get
developers to agree). Suppose that someone can define a reusable PCA
class. This will contain a single "plot" generic function, defined once
and reused by other classes. The existing "plotPCA" interface can also
be implement
Hi Kevin,
I see your points and I agree (especially for the specific case of plotPCA
that involves some non trivial computations).
On the other hand, having a wrapper function that starting from the "raw"
data gives you a pretty picture (with virtually zero effort by the user)
using a sensible ch
Hi,
It depends.
The "traditional" R approach to these matters is that you (a) first
perform some sort of an analysis and save the results as an object and
then (b) show or plot what you got. It is part (b) that tends to be
really generic, and (in my opinion) should have really generic names -
Hi Kevin,
I don't agree. In the case of EDASeq (as I suppose it is the case for
DESeq/DESeq2) plotting the principal components of the count matrix is only
one of possible exploratory plots (RLE plots, MA plots, etc.).
So, in my opinion, it makes more sense from an object oriented point of
view to
I agree it depends on programming style. But to continue with the example,
it would have to be:
plot(as.mySpecialObjectPCA(mySpecialObject))
because we have many packages here with their own functions.
Wouldn't this just proliferate the number of classes instead of functions?
For every type of p
I understand that breaking code is a problem, and that is admittedly the
main reason not to immediately adopt my suggestion.
But as a purely logical exercise, creating a "PCA" object X or something
similar and using either
plot(X)
or
plot(as.PCA(mySpecialObject))
is a much more sensibl
Hi all,
Just a reminder that Hadley is going to submit RSQLite 1.0.0 today.
If your package needs to be changed to work with the new version, and you
haven't already done it, now is the time to make the changes.
You'll need to make them in release and devel.
Thanks,
Dan
- Original Mess
hi Kevin,
that would imply there is only one way to plot an object of a given class.
Additionally, it would break a lot of code.
best,
Mike
On Mon, Oct 20, 2014 at 12:50 PM, Kevin Coombes
wrote:
> But shouldn't they all really just be named "plot" for the appropriate
> objects? In which cas
But shouldn't they all really just be named "plot" for the appropriate
objects? In which case, there would already be a perfectly good generic
On Oct 20, 2014 10:27 AM, "Michael Love"
wrote:
> I noticed that 'plotPCA' functions are defined in EDASeq, DESeq2, DESeq,
> affycoretools, Rcade, fa
I noticed that 'plotPCA' functions are defined in EDASeq, DESeq2, DESeq,
affycoretools, Rcade, facopy, CopyNumber450k, netresponse, MAIT (maybe
more).
Sounds like a case for BiocGenerics.
best,
Mike
[[alternative HTML version deleted]]
___
Bi
13 matches
Mail list logo
