Reduce the number of methods about xcms HOT 4 CLOSED

What could have been the reason we had them as methods initially ?
I am not an expert in R language aesthetics. Would the choice change
if other packages also had group() functions/methods ? What else
influences the choice between function/method ? Happy to get just
a pointer to relevant documents/best practice rather than you having
to elaborate a long answer. Yours, Steffen

from xcms.

It relates a little to lgatto/MSnbase#111 .
Principally, methods only really make sense if they are implemented for at least two different objects; otherwise a function would suffice. Also, as you already mentioned, it makes sense when a generic is defined in another package.
I find also the documentation of functions easier to read (and to create) than for methods.

from xcms.

So this is a no-brainer for specDist and findPeaks, but the name group() might be too
generic to get away with a simple function. Can one easily check the expected fallout
from changing group() ?

from xcms.

I think I was not clear here: I don't want to change group from a method to a function, but the downstream methods group.density, group.nearest etc. To the user this wouldn't change anything.
So, the group, findPeaks and specDist will remain methods (also because in the long run they might be implemented also for OnDiskMSnExp objects in addition to the xcmsRaw).

from xcms.