cyclus/core — Issue #55: simplified way to load/track simple model properties
Author: rwcarlsen
Created: 2012-03-06 17:36:48+00:00
State: open
Labels: Feature, Input Side, Investigate, Module Development

I noticed that on many concrete models, there is a lot of code in xml constructors and copy methods that seems very repetitive. Here is a snippet from recipereactor xml constructor:

```
47 // initialize ordinary objects
48 capacity_ = strtod(XMLinput->get_xpath_content(cur,"capacity"), NULL);
49 //cycle_length_ = strtod(XMLinput->get_xpath_content(cur,"cycletime"), NULL);
50 lifetime_ = strtol(XMLinput->get_xpath_content(cur,"lifetime"), NULL, 10);
51 startConstrYr_ = strtol(XMLinput->get_xpath_content(cur,"startConstrYear"), NULL, 10);
52 startConstrMo_ = strtol(XMLinput->get_xpath_content(cur,"startConstrMonth"), NULL, 10);
53 startOpYr_ = strtol(XMLinput->get_xpath_content(cur,"startOperYear"), NULL, 10);
54 startOpMo_ = strtol(XMLinput->get_xpath_content(cur,"startOperMonth"), NULL, 10);
55 licExpYr_ = strtol(XMLinput->get_xpath_content(cur,"licExpYear"), NULL, 10);
56 licExpMo_ = strtol(XMLinput->get_xpath_content(cur,"licExpMonth"), NULL, 10);
57 state_ = XMLinput->get_xpath_content(cur,"state");
58 typeReac_ = XMLinput->get_xpath_content(cur,"typeReac");
59 CF_ = strtod(XMLinput->get_xpath_content(cur,"elecCF"), NULL);

```

Much of the xml input is simply key-value pairs. capacity=15, state="hello", etc. How feasible would it be to provide a mechanism for developers to do something like this in their input file:
```

15
...

hello
...

... etc.
```

We could conceivably add a std::map, std::map, etc. to the model base class. The xml initialization process could automatically discover and populate these key-value model member vars.

Disbenefits:

* loss of fine-grained control during initialization and copying
* potential for run-time errors - if a key/value doesn't exist - we would likely want to force dev's to use some sort of doubleProperty(name), stringProperty(), functions that would check for non-existing keys
* slightly more complicated "under-the-hood" initialization process.

Benefits:

* Developers would not be forced to use the key-value functionality - they could continue to do things as they are done now if they wished
* Model creation becomes much simpler (lower barrier to entry). For many modules, a developer might not need anything other than key-value pairs of fundamental types. Model creation becomes almost exclusively a matter of coding handleTick/Tock behavior.
* reduce likelyhood of errors in model initialization and copying. This is a very legitimate concern. RecipeReactor actually had a nasty copy bug where a member-var value was not being copied - it took me a while to isolate and correct this bug.

Thoughts?

@gidden, @katyhuff