parallelVectorNames() should return objects that would make sense to
the user when treating your object as an environment, i.e.,
with(ginteractions, anchor1 < anchor2)
The implementation does depend on there being accessors of the same
name, which I think makes sense anyway from the user perspective.
We've tried to follow the convention of the data.frame coercion
yielding a data.frame with column names that match the accessors. If
that is for some reason not sensible for GInteractions, then you'll
need to define your own method. It's just the default heuristic.
Originally, I had used the data.frame implementation only for GRanges
derivatives, but I decided to push it up, because classes should
provide a meaningful implementation. I was torn about it for a while
though.
Michael
On Mon, Feb 22, 2016 at 11:27 AM, Aaron Lun <a...@wehi.edu.au> wrote:
> I've noticed that the parallelVectorNames function definition in S4Vectors
> has changed at commit 113621, from:
>
> setMethod("parallelVectorNames", "ANY", function(x) character())
>
> ... to:
>
> setMethod("parallelVectorNames", "ANY",
> function(x) colnames(as.data.frame(new(class(x)))))
>
> This ends up breaking some of my code at makeFixedColumnEnv(), as it assumes
> that an accessor method exists with the same name as each entry of
> parallelVectorNames(), which is not the case. (Specifically, for my
> genomic interactions class, I have two GRanges representing pairs of anchor
> regions, and as.data.frame yields a data.frame with column names of
> seqnames1, start1, end1, ... and seqnames2, start2, end2, etc. that do not
> have corresponding accessor methods.)
>
> What is the recommended course of action here? Defining an accessor for
> seqnames1, etc. is not impossible, but it seems a bit excessive given that
> those functions would rarely ever be used. Is it okay to restate the old
> definition for the affected class in my package, i.e.:
>
> setMethod("parallelVectorNames", "GInteractions",
> function(x) character())
>
> ... or is there something extra that it should return? I don't really know
> what parallelVectorNames() is designed for, so it's hard to tell.
>
> Cheers,
>
> Aaron
>
> _______________________________________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
