Restructure <epichains>
and <epichains_aggregate_df>
classes
#79
Labels
enhancement
New feature or request
interoperability
refactoring
s3-class
WIP
Work in progress (keep an eye out)
This PR is mostly adding tests, but one issue that I noticed is that
<epichain>
and<epichains_aggregated_df>
objects can inherit from different base classes (data.frame and vector, and data.frame and list, respectively). I'm not sure whether it's a good idea to get into conditional inheritance in this way. This would probably make it difficult for future developers to easily account for what sort of object a function will return. If the data in each case (e.g. epichain_tree vs epichain_summary) is sufficiently different, perhaps it would be better to have separate classes. If you would find an overarching signature more convenient for some methods, the existing classes could be defined as abstract super-classes with sub-classes instead. Happy to discuss this further.Originally posted by @pratikunterwegs in #71 (review)
This issue will be addressed with a PR to:
<epichains_aggregate_df>
that inherits from<list>
while aggregations by either time or generation return a <data.frame> subclass. Associated issues: Remove conditional inheritance fromaggregate
method #81simulate_summary()
to return an<epichains_summary>
class. However, this name is likely to be confused with thesummary()
method and needs some consideration. This will involve:<epichains_summary>
classsimulate_tree()
andsimulate_tree_from_pop()
to return an<epichains_tree>
object. This will involve:<epichains_tree>
classThe text was updated successfully, but these errors were encountered: