Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design - Using dataclasses #71

Open
NicolasGensollen opened this issue Jun 12, 2022 · 0 comments
Open

Design - Using dataclasses #71

NicolasGensollen opened this issue Jun 12, 2022 · 0 comments
Labels
discussion needed A discussion on design should be held before any implementation priority::low Low priority.

Comments

@NicolasGensollen
Copy link
Member

In GitLab by @romaingirard on Jun 12, 2022, 23:35

As suggested by @emaheux in a comment in !80, 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion needed A discussion on design should be held before any implementation priority::low Low priority.
Projects
None yet
Development

No branches or pull requests

1 participant