generics candidates around image/spatial data

[HelenaLC]

Noting down cases we encountered... all open to discussion/suggestions!

• base::table()
• base::data(...)
  • dispatch on ellipsis is problematic
  • SpatialData sets \(x, ...) generic at the moment
• base::scale(x, scale=TRUE, center=TRUE)
  • missing ellipsis/does not allow for other arguments
  • SpatialData sets \(x, ...) generic at the moment
• base::labels(object, ...)
  • SpatialData sets \(x, ...) generic at the moment
  • but \(object, ...) could probably be used instead
• base::sequence(nvec, ...)
  • not sure sure about this one...
  • SpatialData sets \(x, ...) generic at the moment
• base::transform('_data', ...)
  • also S4Vectors::transform('_data', ...)
  • also used by SpatialData
• EBImage::image(x, ...) (generic)
  • perhaps of general interest for its simplicity
  • SpatialData sets \(x, ...) generic at the moment
• EBImage::rotate(x, angle, ...) (function)
  • SpatialData sets \(x, ...) generic at the moment

[hpages]

Thanks Helena. It will take a few days before I can get to this, probably not before Thursday or Friday next week.

[Artur-man]

I agree with @hpages that we should not overdo it, but here are some of the ones I found.

• AnnotationHub::query(x, pattern, ...)
  • breaks SpatialData if loaded.
  • SpatialData sets \(x, ...) generic at the moment
• TBA

[hpages]

I just added data(). See commit 93a0f55. This was also a tricky one, because, in addition to having to deal with the ellipsis like we did with table(), we also need to deal with non-standard evaluation. We also need to be able to handle:

data(sd)

when sd refers to both: an existing dataset and an existing variable. The question is: should we load the dataset or should we dispatch on the data() method defined for objects of the class of sd? I went for the latter which sounds like the sensible thing to do.

So table() and data() are done. I'll wait a couple of days before working on the others in the list, so we get a full build report and can see how much damage this new data() generic is doing. Hopefully the other generics in the list will be less challenging🤞

[hpages]

After scanning the Bioconductor code base, my rough estimate is that we're going to see around 70 software packages with the following R CMD check warning:

* checking whether package ‘ACME’ can be installed ... WARNING
Found the following significant warnings:
  Warning: replacing previous import ‘utils::data’ by ‘BiocGenerics::data’ when loading ‘ACME’
See ‘/home/hpages/git.bioconductor.org/ACME.Rcheck/00install.out’ for details.

I'll extract the exact list once the addition of BiocGenerics::data is reflected on the daily report for BioC 3.24 (it should be tomorrow), and will share it here.