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
This is related to my work in #258 and partially to the refactor in #261.
The results objects at the moment basically implement the common interface defined by the BaseMeasurementResults method and then add property methods to add access to the measured metrics.
After adding the MeasurementResults objects to the RecipeResults array for easier data access for post analysis I think the next logical step is to make the MeasurementResults objects a bit easier to work with in an automated way.
What I'm thinking of is to define a new common interface property or method to access all metrics defined by any specific measurement result object. Something that would basically allow us to do:
A simple dictionary implementation of course works, and is IMO likely to be the best choice here but maybe there's a better solution that I haven't thought of yet.
In addition to that I think that this would allow us to reimplement the Aggregated* result classes in a generic way since we'll simply be able to define their interface as:
This will need a bit more experimentation and a bit more thought into how SPECIFICALLY this will actually extend the individual result classes, but this is the generic idea that I think should be possible and would probably greatly help with both post run analysis, additional calculations, but also code maintainability.
The text was updated successfully, but these errors were encountered:
This is related to my work in #258 and partially to the refactor in #261.
The results objects at the moment basically implement the common interface defined by the
BaseMeasurementResults
method and then add property methods to add access to the measured metrics.After adding the
MeasurementResults
objects to theRecipeResults
array for easier data access for post analysis I think the next logical step is to make theMeasurementResults
objects a bit easier to work with in an automated way.What I'm thinking of is to define a new common interface property or method to access all metrics defined by any specific measurement result object. Something that would basically allow us to do:
A simple dictionary implementation of course works, and is IMO likely to be the best choice here but maybe there's a better solution that I haven't thought of yet.
In addition to that I think that this would allow us to reimplement the
Aggregated*
result classes in a generic way since we'll simply be able to define their interface as:This will need a bit more experimentation and a bit more thought into how SPECIFICALLY this will actually extend the individual result classes, but this is the generic idea that I think should be possible and would probably greatly help with both post run analysis, additional calculations, but also code maintainability.
The text was updated successfully, but these errors were encountered: