Open cvanderaa opened 7 months ago
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 theQFeatures
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.
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!
Currently there are 2 ways to extract a set. Suppose
qf
is aQFeatures
object with 1 or more sets:Option 1. and 2. are the same except that the latter also automatically extracts the
colData
from theQFeatures
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 callingqf[["setOfInterest"]]
, because I don't see a reason why one would want to not havecolData
.What do you think?
If you agree, we could also rethink why
colData
should be stored at the set level within aQFeatures
object. Up to now, I never neededcolData
to be stored in a specific set, and anycolData
in my sets are often the consequence ofaddAssay()
after transforming a set obtained withgetWithColData()
. So, in other words, should we impose that colData is exclusively stored in theQFeatures
object and never in its constituting sets?