Open joshwlambert opened 3 months ago
Question on class standards: When should a element of a class be required versus optional?
In {epiparameter} this relates to the list elements of an <epiparameter>
object. Currently all must be present for the object to be considered valid. But it may be the case that the less important elements (e.g. $notes
) could be removed and the object is still considered valid.
More generally this question could be applied to a class based on a list, or another non-atomic object, or an atomic object using attributes.
From the recent {contactmatrix} dev day I become a bit more familiar with the codebase. The two packages are well aligned from a design perspective. One remaining minor difference is the class name for a dedicated class for a list of objects, <multi_epiparameter>
and <contactmatrix_list>
.
Is it worth renaming one of these so they are consistent, e.g. <epiparameter_list>
or <multi_contactmatrix>
. This would not have any functional different.
@Bisaloo what do you think?
It makes sense from a conceptual point of view but I'd only do it if it's an easy lift.
I'm still slightly unsure which class name makes more sense :thinking:
_list
: https://github.com/search?q=org%3Acran+%2Fclass%5C%28%5Cw%2B%5C%29%5Cs*%28%3C-%7C%3D%29%5Cs*.*%5B%22%27%5D.*_list%5B%22%27%5D%2F&type=codemulti_
: https://github.com/search?q=org%3Acran+%2Fclass%5C%28%5Cw%2B%5C%29%5Cs*%28%3C-%7C%3D%29%5Cs*.*%5B%22%27%5Dmulti_.*%5B%22%27%5D%2F&type=code(Note that this misses cases where class is not set by class<-()
)
The {contactmatrix} R package aims to unify the underlying data structure used by packages that use contact matrices. {epiparameter} aims to do some very similar with its
<epiparameter>
class (previously<epidist>
). Therefore, as these two projects have overlap in their development teams, it makes sense to align their design principles as much as possible.This issue will track those developments.
Tagging @Bisaloo.