[Bioc-devel] [biocpkgs] Bug? in AssayData

[Martin Morgan]

Hi Jan --

Probably these issues belong on bioc-devel (rather than biocpkgs,
where originally posted). Here are some responses:

1. AssayData is a uniquely R class. It is a class union, meaning that
it can contain different types (specifically, 'list' and
'environment'). Even though the slot is defined to contain an
'AssayData' element, in any particular instance the class of the
object in the slot is actually what the occupant of the slot is:

> class(new("ExpressionSet")@assayData)
[1] "environment"
> class(new("ExpressionSet", storage.mode="list")@assayData)
[1] "list"

(Those should be assayData(new("ExpressionSet")), but I'm trying to
avoid any opacity). The role of assayDataElement is to encapsulate an
operation like [[. Doing this in the 'obvious' way does not work:

> setMethod("[[", signature(x="AssayData"), function(x, i, j, ...) 'here')
[1] "[["
> assayData(new("ExpressionSet"))[["exprs"]]
<0 x 0 matrix> # why not 'here'??

this is because 'list' and 'environment' are subclasses of AssayData

> getClass("AssayData")
Extended class definition ( "ClassUnionRepresentation" )
Virtual Class

No Slots, prototype of class "NULL"

Known Subclasses: "list", "environment"

and the methods [[ for list or environment are 'seen' in method
dispatch before the [[ method for AssayData.

I guess there's a philosophical question about when an AssayData
object is really an AssayData object (only when contained in eSet?),
but the functional intention of assayDataElement is to provide
information about AssayData, not about eSet, and hence its residence
in methods-AssayData.R.

2. Notice that the definition of "storageMode" for AssayData is:

setMethod("storageMode", "AssayData", assayDataStorageMode)

i.e., a simple alias for assayDataStorageMode. Using
assayDataStorageMode internally avoids method dispatch, which can
(still) be quite expensive: in assayDataElementNames, obj is an
ExpressionSet, so there would be additional calls to the generic
storageMode, and then to storageMode for eSet, and then storageMode
for assayData, before finally calling assayDataStorageMode.

3. The functions you mention are not exposed (i.e., not exported in
the NAMESPACE file) so should not be considered for 'safe' use by
individuals other than the package developers.

4. Organization of functions in files is not enforced in any way by R,
so this sort of issue is a question of style. Obviously core
Bioconductor packages should provide a style for emulation, and the
use of a class union (also, arguably, method dispatch on more than one
argument, and the use of the class Versioned in the prototype for eSet
[which requires that an 'initialize" method for Versioned be defined
before eSet is defined, and hence that Versioned classes and methods
are defined before DataClasses]) stretch our current conventions about
the 'right' way to do things.

5. If you're still with me, I wonder what the original practical issue
was that lead you to assayDataElement? The intention is that these
details are transparent to the end user, and indeed to most package
developers using Biobase.

Hope that helps,

Martin


"Oosting, J. (PATH)" <J.Oosting at lumc.nl> writes:

> =+=+=+=+=+=+=+=+=+ biocpkgs mailing list +=+=+=+=+=+=+=+=+=
>
> There are 2 functions in methods-AssyData.R from the Biobase package that
> probably belong in methods-eSet, or are not properly implemented.
>
> Both seem to take an eSet as an argument, since assayData is not an AssayData
> method, but assayDataStorageMode is a function for AssayData instances.
>
> I think the assayDataStorageMode() should be replaced by storageMode(), and
> both functions should be moved to methods-eSet.R, because they act on eSets
>
>  
>
> Kind regards,
>
>  
>
> Jan Oosting
>
>  
>
>  
>
>  
>
> current implementation:
>
>  
>
> assayDataElementNames <- function(obj)
>   if (assayDataStorageMode(obj) == "list") names(assayData(obj)) else
> ls(assayData(obj))
>
>  
>
>  
>
> assayDataElement <- function(obj, elt) assayData(obj)[[elt]]
>
>  
> __________________________________________________________________
> biocpkgs mailing list
> To unsubscribe from this mailing list send a blank email to
> biocpkgs-leave at lists.fhcrc.org
> You can also unsubscribe or change your personal options at
> http://lists.fhcrc.org/mailman/listinfo/biocpkgs

-- 
Martin T. Morgan
Bioconductor / Computational Biology
http://bioconductor.org