Question: seqlevels/keepSeqLevels should set default pruning.mode by a getOption call
0
gravatar for matt.chambers42
2.4 years ago by
matt.chambers4210 wrote:

I had some code that worked in 3.4 that was broken by 3.5 adding 'pruning.mode' and making the default mode be an error. It's fine for the default to change, but we should have a way to override it without making the code incompatible with earlier Bioconductor versions (i.e. I get an error if I set pruning.mode in 3.4). Probably the easiest way to achieve this is with getOption(). If the option you look for isn't set, it returns NULL, and then you can fall back to the default mode you have now (an error).

genomeinfodb • 418 views
ADD COMMENTlink modified 2.4 years ago by Hervé Pagès ♦♦ 14k • written 2.4 years ago by matt.chambers4210
Answer: seqlevels/keepSeqLevels should set default pruning.mode by a getOption call
0
gravatar for Hervé Pagès
2.4 years ago by
Hervé Pagès ♦♦ 14k
United States
Hervé Pagès ♦♦ 14k wrote:

Hi Matt,

Note that the default behavior of the seqlevels setter has not changed (has been raising an error if the object needs pruning since the beginning).

I generally try my best to make this kind of changes smoother, typically by using deprecation warnings. I'm not too keen on the idea of using global options to control behaviors like this. IMO global options are fine for controlling things that don't affect the semantic of functions e.g. for display settings. However, in the core infrastructure packages (S4Vectors, IRanges, GenomeInfoDb, GenomicRanges etc..), we've tried to avoid using them to control what functions return.

FWIW we had a lot of discussion internally about what the keepSeqlevels default pruning behavior should be. This discussion was triggered by this post C: keepSeqlevels for GRangesList: drop elements with multiple seqnames from Chao-Jen. With the previous behavior, she was silently loosing some genes! The new default behavior will make the user aware of the pruning mechanism and force him/her to choose a pruning mode. I'm sorry that this breaks some code but OTOH (1) the fix is very easy, and (2) it might help the author of the code realize that maybe s/he was loosing genes.

Best,

H.

ADD COMMENTlink modified 2.4 years ago • written 2.4 years ago by Hervé Pagès ♦♦ 14k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 214 users visited in the last hour