Design - Using dataclasses
As suggested by @emaheux in a comment in !80 (merged), it might be worth exploring whether simple container classes such as IndividualData
and Data
(and even IndividualParameters
?) should be implemented as dataclasses, or even frozen dataclasses. This probably implies radical changes in the construction and API of those classes, which is why this issue attempts to summarize the pros and cons of this change in design, before taking the decision.
To support the discussion, !82 can serve as a preview of the changes implied by using a dataclass (not frozen at this step) for IndividualData
.
Advantages
- More compact, readable and meaningful code
- No need for dummy init values like
None
that introduce annoying edge cases - Meaningful prints and equality testing
- Paradigm shift from sequential construction to one-shot construction based on user pre-defined inputs
Advantages specific to frozen dataclasses:
- Immutability is desirable for objects that are actually used as immutable in practice -> build the instance once and for all
- Mutable attributes can still be muted (but not replaced)
Drawbacks
- Changes radically the construction API
- Requires pre-building most attributes, thus less flexible
Drawbacks specific to frozen dataclasses:
- Incompatible with delayed attribute modifying, e.g. late cofactor loading (at least in the philosophy, since mutable attributes remain mutable)
- Thus even less flexible