Consider the following example:
library(S4Vectors)
hits <- SimpleList(A=SelfHits(1,1,1), B=SelfHits(1,1,1))
## List of length 2
## names(2): A B
endoapply(hits, sort)
## SelfHitsList of length 2
## names(2): A B
Technically speaking, this is not wrong as endoapply guarantees that the return value is of the same class and a SelfHitsList is, after all, a SimpleList. But from a practical perspective, this is a bother as I cannot use the output of endoapply in the same way that I might use a SimpleList, e.g., because I can't assign non-SelfHits to it.
A closely related problem is that as(x, "SimpleList") doesn't actually create a SimpleList, but tends to try to promote things to the most specific form of a list that it can support. For example:
as(list(1,2), "SimpleList")
## NumericList of length 2
## [[1]] 1
## [[2]] 2
In fact, the behavior above is arguably incorrect because a NumericList isn't even a subclass of SimpleList.
The solution may be as simple as adding an argument to coerceToSimpleList to tell it to avoid aggressively promoting the output class within any coerce method towards a SimpleList.
Session information
R version 4.0.0 Patched (2020-05-01 r78341)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS
Matrix products: default
BLAS: /home/luna/Software/R/R-4-0-branch-dev/lib/libRblas.so
LAPACK: /home/luna/Software/R/R-4-0-branch-dev/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] parallel stats4 stats graphics grDevices utils datasets
[8] methods base
other attached packages:
[1] testthat_2.3.2 SingleCellExperiment_1.11.5
[3] SummarizedExperiment_1.19.5 DelayedArray_0.15.4
[5] matrixStats_0.56.0 Matrix_1.2-18
[7] Biobase_2.49.0 GenomicRanges_1.41.5
[9] GenomeInfoDb_1.25.2 IRanges_2.23.10
[11] S4Vectors_0.27.12 BiocGenerics_0.35.4
loaded via a namespace (and not attached):
[1] lattice_0.20-41 bitops_1.0-6 R6_2.4.1
[4] grid_4.0.0 magrittr_1.5 rlang_0.4.6
[7] zlibbioc_1.35.0 XVector_0.29.2 tools_4.0.0
[10] RCurl_1.98-1.2 compiler_4.0.0 GenomeInfoDbData_1.2.3
Consider the following example:
Technically speaking, this is not wrong as
endoapplyguarantees that the return value is of the same class and aSelfHitsListis, after all, aSimpleList. But from a practical perspective, this is a bother as I cannot use the output ofendoapplyin the same way that I might use aSimpleList, e.g., because I can't assign non-SelfHitsto it.A closely related problem is that
as(x, "SimpleList")doesn't actually create aSimpleList, but tends to try to promote things to the most specific form of a list that it can support. For example:In fact, the behavior above is arguably incorrect because a
NumericListisn't even a subclass ofSimpleList.The solution may be as simple as adding an argument to
coerceToSimpleListto tell it to avoid aggressively promoting the output class within anycoercemethod towards aSimpleList.Session information