You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
Upon discussion with the MAE team, it is sensible to have these two behaviors in the general context of MultiAssayExperiment, but this is of limited use for QFeatures and brings more confusion to our users. Tentative implementation:
setMethod("[[", "QFeatures", function(x, i, j, ...) {
getWithColData(x, i, ...)
})
One consideration is that getWithColData() involves much more operations than [[, so a thorough computing benchmark is required.
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?The text was updated successfully, but these errors were encountered: