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}}

