Chromatograms design

[jorainer]

I was thinking a bit about the new Chromatograms object, how it could look like and what it should enable.

The requirements I came up are:

1. support backends
2. have a set of defined chromatogram variables
3. allow to add arbitrary additional chromatogram variables
4. organized as a collection of chromatogram data (no Chromatogram)
5. supports to group data ideally in rows/columns (helpful and user friendly for e.g. xcms workflows).

Current Chromatograms: it extends matrix and organizes Chromatogram object in rows and columns. Not the best design decision, so I'd like to change that.

My proposal for now:

Implement Chromagograms similarly to Spectra:

• @backend slot containing a ChromBackend (or CBackend?).
• organize the data linearly. Same as Spectra, does only allow subsetting by i.

Implement GroupedChromatograms (for point 5) above):

• extends Chromatograms and introduces concept of chromatographic data grouping: default, grouping into rows (ions) and columns (samples).

The reason for the rather clumsy proposal above is: implementing Chromatograms similar to Spectra is straight forward, we can use concepts, ideas and experience gained in Spectra. The GroupedChromatograms gives me the chance to test and evaluate things I need for xcms - without interfering with the Chromatograms implementation.

Any feedback @lgatto @sgibb ?

[lgatto]

Yes for ditching Chromatogram/Chromatograms and follow the design we have adopted in Spectra with back-ends, collections of chromatograms as a single Chromatograms class and a set of defined and arbitrary variables.

I am however not convinced about the need for grouped chromatograms. Would a user-defined variable that defined these groups suffice? Something like

chr[chr$group == "mygroup"]

or

filter(chr, ~ group == "mygroup")

to re-use familiar syntax.

As for the names, I would prefer ChromBackend rather then CBackend. But what about ChrBackend (closer to MsBackend)?

[jorainer]

Let's go for ChromBackend then. Regarding the matrix-like arrangement - that's something we can define later. I have to see how the new Chromatograms works.

[jorainer]

5 years later and wiser ...

We should stick to the layout we have with Spectra - so, a linear organization of data, no matrix-like structure or inherent grouping.

Additional things to lift over from Spectra:

• lazy processing queue (for data manipulation operations) https://github.com/rformassspectrometry/Spectra/blob/main/R/Spectra-functions.R#L10-L53
• built-in chunk-wise processing https://github.com/rformassspectrometry/Spectra/blob/main/R/Spectra-functions.R#L840-L901