[Bioc-devel] Meta data access with $ for GRanges vs RangedData vs data.frame

[Tim Yates]

Obviously, my accessor method was wrong, and missing a check for non-meta
columns:

`$.GRanges`   = function( x, name )        {
  if( name %in% c( 'seqnames', 'ranges', 'strand' ) ) {
    do.call( name, list( x ) )
  }
  else {
    elementMetadata( x )[[ name ]]
  }
}

Sorry about that (it's amazing what you see as soon as you click 'send')


Cheers,

Tim Yates

On 19/03/2012 12:02, "Tim Yates" <TYates at picr.man.ac.uk> wrote:

>Hi all,
>
>I have a feeling I asked this before, but cannot find the mail, or the
>answer I received, so sorry if we're covering old ground.
>
>I have a package which can deal with data.frames, RangedData objects or
>Granges objects.
>
>Assuming I have:
>
>library( IRanges )
>library( GenomicRanges )
>
># Setup a data.frame
>df = data.frame( start=c( 1, 2 ),
>                 end=c( 3, 4 ),
>                 strand=c( '+', '+' ),
>                 name=c( 'tim', 'yates' ),
>                 more=c( T, F ) )
># Setup a RangedData object
>rd = as( df, 'RangedData' )
># Setup a GRanges object
>gr = as( rd, 'GRanges' )
>
>Then the following is the behaviour when trying to use $ for accessing
>the column 'name':
>
>print( df$name )
># [1] tim   yates
># Levels: tim yates
>
>print( rd$name )
># [1] tim   yates
># Levels: tim yates
>
>print( gr$name )
># Error in gr$meta : $ operator not defined for this S4 class
>
>Using it for assignment also gives problems:
>
>df$foo = c( 'bar', 'baz' )
># Adds new column 'foo' to df with values 'bar' and 'baz'
>rd$foo = c( 'bar', 'baz' )
># Adds new column 'foo' to rd with values 'bar' and 'baz'
>gr$foo = c( 'bar', 'baz' )
># Error in `$<-`(`*tmp*`, "foo", value = c("bar", "baz")) :
>#  no method for assigning subsets of this S4 class
>
>Now, if I add the following two methods to my code:
>
>`$.GRanges`   = function( x, name )        {
>  elementMetadata( x )[[ name ]]
>}
>`$<-.GRanges` = function( x, name, value ) {
>  elementMetadata( x )[[ name ]] = value
>  x
>}
>
>Then all the above functions behave in a similar fashion, however I don't
>want to do this in my package, as I believe it will be a gateway to
>namespace hellŠ
>
>Is there any plan to add this accessor operator to Granges so that access
>is normalised across all three of these types?
>
>Thanks!
>
>Tim Yates 
>--------------------------------------------------------
>This email is confidential and intended solely for the ...{{dropped:19}}