I agree with Michael on this. I can see why, in some usage cases, granges() is convenient to have with use.mcols=FALSE (which seems to have been added in the latest release). But in my usage of granges(), where I call granges() on objects like SummarizedExperiments and friends, I have been expecting granges() to give me the GRange component of the object. Not a crippled version of the GRange component.
This is - to me - very counter intuitive and I wish I had seen this earlier. It is particular frustrating that this default is part of the generic. Best, Kasper On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.mich...@gene.com > wrote: > In my opinion, granges() is not very clear as to the intent. The mcols are > part of the GRanges, so why would calling granges() drop them? I think we > want something similar to unclass(), unname(), etc. This why I suggested > dropmcols(). > > > > > On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.tri...@gmail.com > >wrote: > > > That's exactly what I was after -- the generic is already defined, so why > > not use it? > > > > --t > > > > > On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehr...@embl.de> > > wrote: > > > > > > Hi, > > > > > >> On 05.05.2014 16:22, Martin Morgan wrote: > > >> generalize as setMcols, like setNames? setMcols(x, NULL) > > > > > > How about Tim's original suggestion, to add a 'granges' method that > > works on a 'GRanges' input? The current definition > > > > > > granges(x, use.mcols=FALSE, ...) > > > > > > seem suited for this. > > > > > > Best wishes > > > Julian > > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
