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
Should there be a consistent policy here? IMO it would make most sense to c the metadata lists, removing duplicate names (plus a warning if their values are not identical). This has the nice properties of:
Preserving most information, provided that they have different names in the various objects. TBH, the lost information might not be too bad; list elements with the same name but different values aren't that helpful in downstream analyses anyway, especially if we no longer have the knowledge about which of the original objects they came from.
Ensuring that, e.g., cbind(df[,0], df) would give back df. This wouldn't be the case if you just continually appended the metadata lists together, which would arbitrarily extend the metadata list in the bind'd object.
One could even imagine writing a combineMetadata() function that all Annotated subclasses can call, so as to easily combine the metadata() fields in a standard way for c, rbind, cbind, combineRows, combineCols, etc. etc.
The text was updated successfully, but these errors were encountered:
Consider:
That's fine, I guess. But then:
Should there be a consistent policy here? IMO it would make most sense to
c
the metadata lists, removing duplicate names (plus a warning if their values are not identical). This has the nice properties of:cbind(df[,0], df)
would give backdf
. This wouldn't be the case if you just continually appended themetadata
lists together, which would arbitrarily extend themetadata
list in the bind'd object.One could even imagine writing a
combineMetadata()
function that allAnnotated
subclasses can call, so as to easily combine themetadata()
fields in a standard way forc
,rbind
,cbind
,combineRows
,combineCols
, etc. etc.The text was updated successfully, but these errors were encountered: