On Mon, May 20, 2013 at 3:11 PM, Martin Morgan <mtmor...@fhcrc.org> wrote:
> Hi Michael --
>
>
> On 5/20/2013 5:56 AM, Michael Lawrence wrote:
>
>> While it's cool that seqlevels<- has become so flexible, I still claim
>> that
>> rename/keep/drop would be a lot easier to read, because they describe the
>> high-level operation, and there's no reason to deprecate them. They're
>> also
>> easier to remember. For example, for dropping with seqlevels<-, the user
>> needs
>> to remember that "force" is necessary to drop. Much easier to just say
>> "dropSeqlevels(), please". And reimplementing keepSeqlevels is still too
>> complicated. Is it such a maintenance burden to have these simple
>> wrappers sit
>> on top of the low-level manipulators?
>>
>> Another suggestion: renameSeqlevels should not require a named vector (in
>> cases
>> where it is unnamed, require that it is parallel to the existing
>> seqlevels, as
>> with seqlevels<-).
>>
>
> I didn't really indicate what drove my desire to see keepSeqlevels
> deprecated. keepSeqlevels, seqlevels<-, and isActiveSeq were developed more
> or less independently, and have different contracts. The different
> contracts are confusing to the user, as is creating a usable help system
> when there are multiple end points for what is a common operation. The help
> pages of each were inadequate in different ways. And because the code was
> developed independently, support for different objects was inconsistent. So
> actually, yes, the maintenance (and use) burden for the previous state of
> affairs was substantial.
>
> On the other hand, I agree that keepSeqlevels is convenient as a simple
> wrapper around seqlevels<-, in the same way that setNames and names<- are
> both useful.
>
> So we could iterate to
>
> keepSeqlevels <-
> function(x, value, ...)
> {
> seqlevels(x, force=TRUE) <- value
> x
> }
>
> but I'd be less enthusiastic about maintaining the original contract of
> keepSeqlevels, where keepSeqlevels(gr1, gr2), would have worked for two
> GRanges objects.
>
>
Well, I wasn't even aware of that feature, so you've made your point about
the documentation ;) Sounds like a good compromise to me.
Thanks for understanding,
Michael
> Martin
>
>
>> Michael
>>
>>
>>
>>
>>
>>
>> On Sat, May 18, 2013 at 6:00 PM, Martin Morgan <mtmor...@fhcrc.org
>> <mailto:mtmor...@fhcrc.org>> wrote:
>>
>> On 05/18/2013 05:42 PM, Martin Morgan wrote:
>>
>> Some of the most common operations are straight-forward, e.g.,
>>
>> > gr = GRanges(paste0("chr", c(1:22, "X", "Y")), IRanges(1,
>> 100))
>> > seqlevels(gr) = sub("chr", "ch", seqlevels(gr))
>>
>>
>> To get a more comprehensive example I should have followed my own
>> advice and
>> grabbed from the help page!
>>
>> ## Rename:
>> seqlevels(txdb) <- sub("chr", "", seqlevels(txdb))
>> seqlevels(txdb)
>>
>> seqlevels(txdb) <- paste0("CH", seqlevels(txdb))
>> seqlevels(txdb)
>>
>> seqlevels(txdb)[seqlevels(__**txdb) == "CHM"] <- "M"
>>
>> seqlevels(txdb)
>>
>>
>> --
>> Computational Biology / Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N.
>> PO Box 19024 Seattle, WA 98109
>>
>> Location: Arnold Building M1 B861
>> Phone: (206) 667-2793 <tel:%28206%29%20667-2793>
>>
>>
>>
>
> --
> Dr. Martin Morgan, PhD
>
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
