Same here, I understand the desire for consistency but
keepSeqlevels/dropSeqlevels just makes more sense
--t
On May 18, 2013, at 5:42 PM, Kasper Daniel Hansen
<kasperdanielhan...@gmail.com> wrote:
> For the second time today, I find myself fully supporting Michael's
> suggestion.
>
>
> On Sat, May 18, 2013 at 8:18 PM, Michael Lawrence <lawrence.mich...@gene.com
>> wrote:
>
>> Hi guys,
>>
>> Just wondering about the rationale of deprecating keepSeqlevels and
>> renameSeqlevels. Sure, it's possible to do those things with seqlevels,
>> somehow, but those functions make the high-level operation fairly obvious.
>> They're very well named, and correspond to typical operations. I don't
>> think we should deprecate functions just because they are simple wrappers
>> on top of lower level functions. I might even suggest adding a
>> dropSeqlevels(), e.g. dropSeqlevels("chrM").
>>
>> As I understand it, instead of:
>> keepSeqlevels(x, "chr1")
>>
>> We need to do something like:
>> seqlevels(x, new2old = 1, force = TRUE) <- "chr1"
>> But to be more careful it would be:
>> seqlevels(x, new2old = match("chr1", seqlevels(x)), force = TRUE) <- "chr1"
>>
>> This seqlevels stuff is already confusing to people and the above lines are
>> regular visitors on my office white-board. These changes will probably
>> cause me to sacrifice yet more of my white-board.
>>
>> In the future, perhaps we should propose these deprecations on the mailing
>> list for discussion, before any code changes.
>>
>> Michael
>>
>> [[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
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
