Its time to end the XML input antipattern

[PDoakORNL]

Issue:
XMLNodePtr is the (void*) of QMCPack

class ICouldDoAnything
{
  MyObjectCouldBeAnything(Communicate *);
  void put(void* cur);
}

Not only do we construct most important objects in two or more stages but this construction/initialization is driven by what amounts to void*'s.

This has to end. As void* will it evades the type system, cannot be reasoned about in the code, and allows the develop to never clearly specify the actual contents of the void*.

Going forward I propose that no new functionality be added with this pattern. At some point we have to draw a line in the sand or we'll never break free of this.

I found it relatively easy to separate input parsing, and default parameter values for the drivers into QMCDriver_input, DMCDriver_input, VMCDriver_input. If XML parsing is decoupled from object construction then objects can actually be created by constructors.

A rational basis for a valid and testable code requires clear input parameter sets expressed in native typed C++. For the developer these should be documented in doxygen comments at declaration rather than in the xml parameter tables of the manual. The manual is primarily for our users and should document the scientific and other aspects of the input from the users perspective.

Additionally the manual should not contain components under development while these components should be documented via doxygen compatible comments as they are written.

Deliverable(s):

• Specification/Directions for adding input and bringing an input dependent class to a valid state.

[ye-luo]

It really depends. I think for classes don't have a proper builder handling XML and use put() in the final object this is probably a good way to go. The key goal is not adding any more copies of parameters. If it is stored in the input class, it must be consumed directly in every place using these parameters inside the object.

[PDoakORNL]

As a goal no object should have a put. Either they are created by a factory or have constructors that express their actual requirements.