Search
Question: DEXUSResult as.data.frame doesn't work well if topGO is loaded
0
gravatar for idavydov
3 months ago by
idavydov0
idavydov0 wrote:

I noticed that as.data.frame method does not work for DEXUSResult if topGO is loaded.

Not sure who's fault is it and where to report the bug.

Any suggestions?

Thanks.

The code:

library(dexus)
nrow(as.data.frame(dexus(matrix(rbinom(100, 100, 0.1), nrow=10))))
library(topGO)
nrow(as.data.frame(dexus(matrix(rbinom(100, 100, 0.1), nrow=10))))

With output

library(dexus)
#> Loading required package: BiocGenerics
#> Loading required package: parallel
#> 
#> Attaching package: 'BiocGenerics'
#> The following objects are masked from 'package:parallel':
#> 
#>     clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
#>     clusterExport, clusterMap, parApply, parCapply, parLapply,
#>     parLapplyLB, parRapply, parSapply, parSapplyLB
#> The following objects are masked from 'package:stats':
#> 
#>     IQR, mad, sd, var, xtabs
#> The following objects are masked from 'package:base':
#> 
#>     anyDuplicated, append, as.data.frame, basename, cbind,
#>     colMeans, colnames, colSums, dirname, do.call, duplicated,
#>     eval, evalq, Filter, Find, get, grep, grepl, intersect,
#>     is.unsorted, lapply, lengths, Map, mapply, match, mget, order,
#>     paste, pmax, pmax.int, pmin, pmin.int, Position, rank, rbind,
#>     Reduce, rowMeans, rownames, rowSums, sapply, setdiff, sort,
#>     table, tapply, union, unique, unsplit, which, which.max,
#>     which.min
#> 
#> Attaching package: 'dexus'
#> The following object is masked from 'package:BiocGenerics':
#> 
#>     sizeFactors
nrow(as.data.frame(dexus(matrix(rbinom(100, 100, 0.1), nrow=10))))
#> Filtered out 0 % of the genes due to low counts
#> Unsupervised mode.
#> [1] 10
library(topGO)
#> Loading required package: graph
#> Loading required package: Biobase
#> Welcome to Bioconductor
#> 
#>     Vignettes contain introductory material; view with
#>     'browseVignettes()'. To cite Bioconductor, see
#>     'citation("Biobase")', and for packages 'citation("pkgname")'.
#> 
#> Attaching package: 'Biobase'
#> The following object is masked from 'package:dexus':
#> 
#>     sampleNames
#> Loading required package: GO.db
#> Loading required package: AnnotationDbi
#> Loading required package: stats4
#> Loading required package: IRanges
#> Loading required package: S4Vectors
#> 
#> Attaching package: 'S4Vectors'
#> The following object is masked from 'package:dexus':
#> 
#>     params
#> The following object is masked from 'package:base':
#> 
#>     expand.grid
#> 
#> Loading required package: SparseM
#> 
#> Attaching package: 'SparseM'
#> The following object is masked from 'package:base':
#> 
#>     backsolve
#> 
#> groupGOTerms:    GOBPTerm, GOMFTerm, GOCCTerm environments built.
#> 
#> Attaching package: 'topGO'
#> The following object is masked from 'package:IRanges':
#> 
#>     members
nrow(as.data.frame(dexus(matrix(rbinom(100, 100, 0.1), nrow=10))))
#> Filtered out 0 % of the genes due to low counts
#> Unsupervised mode.
#> Error in as.data.frame.default(dexus(matrix(rbinom(100, 100, 0.1), nrow = 10))): cannot coerce class 'structure("DEXUSResult", package = "dexus")' to a data.frame
ADD COMMENTlink modified 3 months ago by James W. MacDonald48k • written 3 months ago by idavydov0
2
gravatar for James W. MacDonald
3 months ago by
United States
James W. MacDonald48k wrote:

There is always the possibility that a package will mask a function in an earlier loaded package. The fix for that is to use the fully qualified function name, which in this case appears to be dexus::as.data.frame.

ADD COMMENTlink written 3 months ago by James W. MacDonald48k

Thanks, James. This helps.

I thought that as.data.frame is a generic function with different methods for different classes. And name conflict only could arise in case of class names clash.

But now I see that dexus authors just rewritten as.data.frame instead of creating as.data.frame.DEXUSResult or something like this. The same was done in BiocGenerics. Seems like a bug/bad software design to me; but maybe I'm missing something.

Thanks for your help.

ADD REPLYlink written 12 weeks ago by idavydov0
1

BiocGenerics defines an S4 generic as.data.frame that has as it's default method base::as.data.frame. The effect is to either handle the S4 object, or if the object is not an S4 object / does not have an S4 as.data.frame method to let base::as.data.frame do it's job. Thus BiocGenerics implements S4 dispatch on top the S3 generic rather than masking the base function. topGO adds BiocGenerics to the search path.

dexus does the same thing -- defines an S4 generic with default behavior to dispatch to base::as.data.frame.

The problem is thus that there are two separate generics, with separate S4 methods. Since dexus already imports BiocGenerics, the right thing to do is for the maintainer to use BiocGenerics::as.data.frame rather than defining there own. I've asked the maintainer to do this.

ADD REPLYlink written 12 weeks ago by Martin Morgan ♦♦ 22k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.2.0
Traffic: 327 users visited in the last hour