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@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@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@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]]

