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

[Oosting, J. (PATH)]

Hi Morgan,

My issue is with  assayDataElementNames(), I just stumbled across assayDataElement when I checked an error that popped up recently.

I have an eSet subclass that has optional elements in assayData

I use something like
if ( !("intensity" %in% assayDataElementNames(object))) object<-CalculateIntensity(object)


When the object has storageMode=="list" I get an error, because the function assayDataStorageMode tests this assuming the argument is an AssyData instance, but the following commands in the function assume this is an eSet instance.

> assayDataElementNames <- function(obj)
>   if (assayDataStorageMode(obj) == "list") names(assayData(obj)) else
> ls(assayData(obj))

This should either be:
if (assayDataStorageMode(assayData(obj)) == "list")
or
if (storageMode(obj) == "list")


>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.
>
As I argue above there is ambiguity abouth the class of object that assayDataElementNames expects, and in the past it worked well with eSet-descendants

>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.
>
They are exposed in the export() part of the NAMESPACE

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

I realize that the placement of functions in sourcefiles is arbitrary, but these two functions act on eSets, their placement in the AssayData source file induced in someone the conclusion that the reasoning in your point 2 is valid, so the dispatch could be circumvented.

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




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