First of all, I still need to decide if this is a good idea.
whatami focus is on simple and consistent id string generation, but being able to regenerate the objects could be a plus. However, whenever this is done, it should impose no more API requirements to the whatamised objects, as we want whatami to stay simple, general accross many different libraries and unobtrusive for new libraries.
That means that reconstruction should be handled by external factories that know how to instantiate and configure the objects. For example, a factory could know how to map names to instantiation mechanism:
"rfc#depth=10"->sklearn's RandomForestClassifier, use sklearn constructor for configuration contract;
"hnb#use_laplace=True" -> weka's HiddenNaiveBaye and use setOptions or setter methods;
'foo#bar=3' -> unpickle the object from a repository in disk).
As usual, special care should be given to nested configurations.
A factory that maps id strings to objects, plus a mechanism where we can plug factories into WhatamiTreeVisitor, mapping names to concrete factories, would probably make the trick.
First of all, I still need to decide if this is a good idea.
whatami
focus is on simple and consistent id string generation, but being able to regenerate the objects could be a plus. However, whenever this is done, it should impose no more API requirements to the whatamised objects, as we want whatami to stay simple, general accross many different libraries and unobtrusive for new libraries.That means that reconstruction should be handled by external factories that know how to instantiate and configure the objects. For example, a factory could know how to map names to instantiation mechanism:
As usual, special care should be given to nested configurations.