Assume the object is backed by an HDF5 or Zarr array, for the sake of argument and because that’s kind of how it works these days for many people. Also assume the “SE*” may not actually be an SE, but rather some wacky subclass of SE.
If you return a new SE*, you need to copy all the metadata, any weird slots that subclasses of SE have added, etc. and you need to make sure you’re returning what you think you are. This has been an issue for me sometimes when converting SE-like objects to HDF5Array-backed SE-like objects (eg GenomicRatioSet). If you just add the assay to SE*, you may be writing HDF5 or Zarr to disk for a while, but at least you don’t have to care what all else SE* contains or does. That’s the subclasser’s problem. If their methods suck, file a PR and let them merge it! Meanwhile your functions can call doProcess(SE*) if they notice that its output is missing when it ought to be present, and regardless of what SE* really is, they ought to work. You could check to see if SE* is some type of object for which doProcess() is inappropriate, but on balance, I’d add the assay and return SE* as itself. --t > On Jan 28, 2020, at 4:38 AM, Laurent Gatto <laurent.ga...@uclouvain.be> wrote: _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
