As we no longer use nested node (each datamodel = 1 node) and are considering dropping support for old multi-node datamodels we may also want to consider if the dynamic creation of nodes is helpful.
At this point any new nodes would only be introduced if we introduce a new datamodel. In that case we currently still have to make paired rad/roman_datamodels PRs since datamodel creation is not dynamic.
It seems straightforward to:
- freeze the current dynamic nodes
- deprecate/drop those we don't want to support in the future
The benefits are:
- significantly simplify roman_datamodels internals
- remove many of the "mixin" classes which complicate datamodel maintenance by spreading behavior across files and objects
- (likely) reduce the overhead of roman_datamodels import (which could be a minor issue for multiprocessing where each process may be subject to the import overhead)
- static code inspection of nodes would be possible
The cons are:
- significant changes to roman_datamodels internals requiring time from all maintainers
- minor increase in code needed to support a new datamodel (as a new node will also need to be created) for simple cases this would be an extra 3 or 4 lines of code
This would have no impact on public API.
As we no longer use nested node (each datamodel = 1 node) and are considering dropping support for old multi-node datamodels we may also want to consider if the dynamic creation of nodes is helpful.
At this point any new nodes would only be introduced if we introduce a new datamodel. In that case we currently still have to make paired rad/roman_datamodels PRs since datamodel creation is not dynamic.
It seems straightforward to:
The benefits are:
The cons are:
This would have no impact on public API.