Currently, metrics() is a bit overloaded with functionality. It provides an interface to both
- view available metrics using
metrics() which returns a list<pkg_data_info> (list of metric metadata)
- calculate metrics for a package, which returns a
list<class_atomic> (list of metric results)
I think this is too unclear and we should probably split them up.
Proposed split
-
available_metrics as a generic over parameter x, such a that
x is of class class_character: returns an available.packages()-style matrix, currently implemented in val.criterion:::available_metrics
x is of class class_pkg: returns the metrics that can be derived given the package's specific resources
x is a class_resource: returns the metrics available for a specific resource type
-
derive_metrics which calculates the metrics themselves. Only needs to be implemented for class_pkg and maybe list<class_pkg>... not even sure it needs to be generic.