Create base class that `Proj`, `Model`, and `Run` all inherit from

[spencerahill]

The data structures Proj, Model, and Run don't obey an "is-a" conceptual relationship relative to one another (a model is not a type of project, and a run is not a type of model), and thus shouldn't inherit from each other. It's more of a "has-a" relationship: a project has one or more model; a model has one or more runs).

Nevertheless, each of them can be conceptualized as being a particular kind of container of data describing climate model/obs data saved somewhere on disk. So there should be a parent class, something like InputDataSpecs, that they each inherit from. Since we are wanting all specifications about the data to be made at any of the levels, c.f. #28 #27 and #26, this could be implemented all within this parent class, with any level-specific variations being done through overriding/adding methods within that particular child level. This may ultimately render the Proj, etc. classes with very little unique to them, but they should still be retained to facilitate easy organization/calculation specifications.

Var is a little trickier, because in addition to specifying where the data can be found (although its not really used in this way in my workflow at least), it also specifies physical aspects of the quantity being represented. So this requires more thinking -- one option would be to have two classes, one for each of these functions, with the former also inheriting from this parent class.

[spencerkclark]

This sounds like a solid strategy for how to consolidate code for like functionality in Proj, Model, and Run.

With regard to Var could you clarify what you mean by "specifying where the data can be found?" I don't believe I use it this way in my workflow either. Is there a reason to support such functionality?

[spencerahill]

Sure. I mean that we should support mappings of variables to the external data at the level of a Var (in which case obviously it would be of that one variable). For example, suppose because of a postprocessing error, all of the variables can be found using a simple mapping except for one. Then, the user could create a Var object with the mapping unique to that variable's data.

Now that I've written that out, I'm convinced that this type of functionality should be separate from what Var does in its current form, namely specify physical/functional parameters about a particular physical quantity. Maybe keep Var intact and create VarData for the data-finding stuff.

[spencerkclark]

Cool, that makes sense. I hadn't thought about exceptions to implicit file mappings. I agree about keeping this outside the current Var class. Perhaps we could just have an argument in creating a FileMapGenerator that allowed the user to add custom mappings for specific variables that would override the implicit mapping?

[spencerahill]

We could do that as well, but I think it still would be good to have a data-container style of object (i.e. the envisioned VarData) that represents the level of individual variables.

Not a high priority though...in fact none of this refactor is for me until at least mid-January. I create these issues as things come to mind, since its the most sensible place for them, but I realistically won't be able to do much substantive on these (beyond what naturally arises from my work) for the next couple of months.

[spencerahill]

C.f. discussion in #156, considering adding a ObjectLibrary level above Proj in the hierarchy.

This would be in addition to, not in place of, the core object that all inherit from under discussion here.