[Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...

[Cook, Malcolm]

Wondering,

Is it too off the beaten track to expect

`mcols<-`(x,NULL) 

to work?

hint: it does not

 >-----Original Message-----
 >From: bioc-devel-bounces at r-project.org [mailto:bioc-devel-bounces at r-project.org] On Behalf Of Hervé Pagès
 >Sent: Monday, May 05, 2014 1:28 PM
 >To: Kasper Daniel Hansen; Michael Lawrence
 >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org
 >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
 >
 >Hi,
 >
 >I have no problem using granges() for that. Just to clarify:
 >   (a) it would propagate the names()
 >   (b) it would drop the metadata()
 >   (c) the mcols() would propagate only if 'use.mcols=TRUE' was
 >       specified ('use.mcols' is FALSE by default)
 >   (d) it would return a GRanges *instance* i.e. input object 'x'
 >       would be downgraded to GRanges if it extends GRanges
 >
 >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols'
 >arg and always propagates the mcols. Alternatively you can use rowData()
 >which also propagates the mcols. granges() is actually just an alias
 >for rowData() on SummarizedExperiment objects.
 >
 >H.
 >
 >
 >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote:
 >> 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.michael at 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.triche at 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.gehring at 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 at r-project.org mailing list
 >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
 >>>
 >>
 >> 	[[alternative HTML version deleted]]
 >>
 >> _______________________________________________
 >> Bioc-devel at 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: hpages at fhcrc.org
 >Phone:  (206) 667-5791
 >Fax:    (206) 667-1319
 >
 >_______________________________________________
 >Bioc-devel at r-project.org mailing list
 >https://stat.ethz.ch/mailman/listinfo/bioc-devel