Study need for high-level interface for accessing results

[jared321]

For the upcoming release, the public interface will include a set of similar, related parse_* functions that each returns a specific, different set of data parsed out of a given Frescox output file. Should the public interface also include a high-level public interface for accessing this same data?

It would make sense that the high-level interface perform as much work as possible using those same parse_* functions, which would be considered the low-level interface. In such a case, we would have to decide if the the low-level functions remain in the public interface or are transferred to the private interface (Issue #26).

Arguments for putting a class-based (e.g., Results) facade over the parse_* functions

• the functions are clearly related and could benefit from being explicitly grouped beyond similarities in their names
• the functions all take a filename argument, which is akin to a self argument if the class stores the filename internally
• the functions can each be written to parse out data from only one of many different output files. The developers of each function should determine which file is the best source of the data (e.g., easier to parse out correctly or reported with more precision)
• a constructor could be passed a single folder than contains a full set of Frescox output files from a single run (i.e., the folder is conceptually the Frescox output "file") and data access member functions of the class would be encoded to know which internal file needs to be passed to which parse_* function. This hides such internal details from users of the high-level interface.