Use of non-exported `clone` function from GenomicRange package
1
0
Entering edit mode
Peter Hickey ▴ 740
@petehaitch
Last seen 10 weeks ago
WEHI, Melbourne, Australia
I have defined a class `CoMeth` that is basically a `SummarizedExperiment`. However, one difference is that I store some important information in the metadata columns of the rowData, i.e. in `mcols(rowData(x))`, where `x` is a CoMeth object. I don't want the user to accidentally overwrite/remove this information if they update the `mcols` so I defined the following replacement method: ``` setReplaceMethod("mcols", signature = "CoMeth", function(x, ..., value){ if (any(grepl(pattern = "^pos", colnames(value)))){ # The columns I don't want overwritten/removed all begin with "pos" stop("Column names of user-specified 'mcols' must not begin with 'pos'") } GenomicRanges:::clone(x, rowData = local({ r <- rowData(x) mcols(r) <- cbind(mcols(rowData(x)), value) # The new mcols are added to the existing mcols. r })) }) ``` This method is based on the `mcols<-` method defined for the `SummarizedExperiment` class and relies on the non-exported `clone` function from the GenomicRanges package So my questions are: 1. Is it okay to rely on `clone`? 2. If not, can someone suggest an alternative way to achieve the same idea? 3. Is this the correct way to call `clone` in my package (which already depends on the GenomicRanges package)? Thanks, Pete -------------------------------- Peter Hickey, PhD Student/Research Assistant, Bioinformatics Division, Walter and Eliza Hall Institute of Medical Research, 1G Royal Parade, Parkville, Vic 3052, Australia. Ph: +613 9345 2324 hickey@wehi.edu.au http://www.wehi.edu.au ______________________________________________________________________ The information in this email is confidential and intend...{{dropped:8}}
GenomicRanges GenomicRanges • 1.1k views
ADD COMMENT
0
Entering edit mode
@michael-lawrence-3846
Last seen 2.8 years ago
United States
You might think about the modularity of your design. Would it make sense for these constraints to apply to the rowData independent of the CoMeth object? In other words, do you need a CoMethRanges class that extends GRanges? If so, you might want to look at the extraColumnNames generic; one can define a method that names the fixed column slots added by CoMethRanges, and the framework behaves accordingly. If you decide against that, you'll also need to check the extra constraints in the rowData<- method, and maybe other places. That all said, I think your logic is incorrect in mcols<-. The operation is not a cbind but rather a replacement, i.e., you would want mcols(rowData(x)) <- value. But really, I think you want to rely on callNextMethod() here; there is no need to call clone() at all. Best of luck, Michael On Sun, Mar 23, 2014 at 7:48 PM, Peter Hickey <hickey@wehi.edu.au> wrote: > I have defined a class `CoMeth` that is basically a > `SummarizedExperiment`. However, one difference is that I store some > important information in the metadata columns of the rowData, i.e. in > `mcols(rowData(x))`, where `x` is a CoMeth object. I don't want the user to > accidentally overwrite/remove this information if they update the `mcols` > so I defined the following replacement method: > > ``` > setReplaceMethod("mcols", signature = "CoMeth", function(x, ..., value){ > if (any(grepl(pattern = "^pos", colnames(value)))){ # The columns I > don't want overwritten/removed all begin with "pos" > stop("Column names of user-specified 'mcols' must not begin with > 'pos'") > } > > GenomicRanges:::clone(x, rowData = local({ > r <- rowData(x) > mcols(r) <- cbind(mcols(rowData(x)), value) # The new mcols are added > to the existing mcols. > r > })) > }) > ``` > > This method is based on the `mcols<-` method defined for the > `SummarizedExperiment` class and relies on the non-exported `clone` > function from the GenomicRanges package > > So my questions are: > 1. Is it okay to rely on `clone`? > 2. If not, can someone suggest an alternative way to achieve the same idea? > 3. Is this the correct way to call `clone` in my package (which already > depends on the GenomicRanges package)? > > Thanks, > Pete > > > -------------------------------- > Peter Hickey, > PhD Student/Research Assistant, > Bioinformatics Division, > Walter and Eliza Hall Institute of Medical Research, > 1G Royal Parade, Parkville, Vic 3052, Australia. > Ph: +613 9345 2324 > > hickey@wehi.edu.au > http://www.wehi.edu.au > > > ______________________________________________________________________ > The information in this email is confidential and inte...{{dropped:13}}
ADD COMMENT
0
Entering edit mode
Thanks for giving me plenty to think about, Michael. That's very useful. Yes, it does make sense for these constraints to apply to the rowData independent of the CoMeth object. Can you point me in the direction of a class that extends Granges and/or that uses the extraColumnNames generic. As Martin pointed out to me in a previous post, my design of the CoMeth class as an extension of the SummarizedExperiment class is a bit of a "square peg round hole" scenario. Hmm, designing classes is hard. Perhaps I need to go back to the drawing board. Thanks, Pete On 24/03/2014, at 3:03 PM, Michael Lawrence <lawrence.michael@gene.com> wrote: > You might think about the modularity of your design. Would it make sense for these constraints to apply to the rowData independent of the CoMeth object? In other words, do you need a CoMethRanges class that extends GRanges? If so, you might want to look at the extraColumnNames generic; one can define a method that names the fixed column slots added by CoMethRanges, and the framework behaves accordingly. > > If you decide against that, you'll also need to check the extra constraints in the rowData<- method, and maybe other places. > > That all said, I think your logic is incorrect in mcols<-. The operation is not a cbind but rather a replacement, i.e., you would want mcols(rowData(x)) <- value. But really, I think you want to rely on callNextMethod() here; there is no need to call clone() at all. > > Best of luck, > Michael > > > On Sun, Mar 23, 2014 at 7:48 PM, Peter Hickey <hickey@wehi.edu.au> wrote: > I have defined a class `CoMeth` that is basically a `SummarizedExperiment`. However, one difference is that I store some important information in the metadata columns of the rowData, i.e. in `mcols(rowData(x))`, where `x` is a CoMeth object. I don't want the user to accidentally overwrite/remove this information if they update the `mcols` so I defined the following replacement method: > > ``` > setReplaceMethod("mcols", signature = "CoMeth", function(x, ..., value){ > if (any(grepl(pattern = "^pos", colnames(value)))){ # The columns I don't want overwritten/removed all begin with "pos" > stop("Column names of user-specified 'mcols' must not begin with 'pos'") > } > > GenomicRanges:::clone(x, rowData = local({ > r <- rowData(x) > mcols(r) <- cbind(mcols(rowData(x)), value) # The new mcols are added to the existing mcols. > r > })) > }) > ``` > > This method is based on the `mcols<-` method defined for the `SummarizedExperiment` class and relies on the non-exported `clone` function from the GenomicRanges package > > So my questions are: > 1. Is it okay to rely on `clone`? > 2. If not, can someone suggest an alternative way to achieve the same idea? > 3. Is this the correct way to call `clone` in my package (which already depends on the GenomicRanges package)? > > Thanks, > Pete > > > -------------------------------- > Peter Hickey, > PhD Student/Research Assistant, > Bioinformatics Division, > Walter and Eliza Hall Institute of Medical Research, > 1G Royal Parade, Parkville, Vic 3052, Australia. > Ph: +613 9345 2324 > > hickey@wehi.edu.au > http://www.wehi.edu.au > > > ______________________________________________________________________ > The information in this email is confidential and inte...{{dropped:31}}
ADD REPLY
0
Entering edit mode
Hi Pete, On Sun, Mar 23, 2014 at 10:32 PM, Peter Hickey <hickey at="" wehi.edu.au=""> wrote: > Thanks for giving me plenty to think about, Michael. That's very useful. Yes, it does make sense for these constraints to apply to the rowData independent of the CoMeth object. Can you point me in the direction of a class that extends Granges and/or that uses the extraColumnNames generic. The VRanges classes in the VariantAnnotation package is one such class. It extends GRanges and adds a few more columns, like 'ref', 'alt' (and more). I think the method name you want to look for is "GenomicRanges:::extraColumnSlotNames", although I'm not sure why this function isn't exported if it's something other packages should be using / defining methods for. HTH, -steve -- Steve Lianoglou Computational Biologist Genentech
ADD REPLY

Login before adding your answer.

Traffic: 672 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6