Rethinking colData management when adding or extracting sets

[cvanderaa]

Currently there are 2 ways to extract a set. Suppose qf is a QFeatures object with 1 or more sets:

qf[["setOfInterest"]] ## 1.
getWithColData(qf, "setOfInterest") ## 2.

Option 1. and 2. are the same except that the latter also automatically extracts the colData from the QFeatures object to the extracted set. However, the former feels more natural in the R language and I often see users using 1. while in fact they need 2.

My suggestion would be to merge 1. and 2., that is to always internally rely on getWithColData() when calling qf[["setOfInterest"]], because I don't see a reason why one would want to not have colData.

What do you think?

If you agree, we could also rethink why colData should be stored at the set level within a QFeatures object. Up to now, I never needed colData to be stored in a specific set, and any colData in my sets are often the consequence of addAssay() after transforming a set obtained with getWithColData(). So, in other words, should we impose that colData is exclusively stored in the QFeatures object and never in its constituting sets?

[lgatto]

What do you think?

Yes, good idea to avoid problems with [[. But I would be curious to hear what to reason is to keep them separate in MultiAssayExperiment. If they have a good reason, we might reconsider/discuss. Could you ask?

So, in other words, should we impose that colData is exclusively stored in the QFeatures object and never in its constituting sets?

There is not obligation to have a set-level colData, and I don't see why we should forbid it.

[cvanderaa]

Yes, good idea to avoid problems with [[. But I would be curious to hear what to reason is to keep them separate in MultiAssayExperiment. If they have a good reason, we might reconsider/discuss. Could you ask?

Good advice! I'll do it!