Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 298
Decide on extent of OOP in metadata model #1133
Copy link
Copy link
Closed
Labels
decision recordOutcome of this discussion should be tracked in a decision recordOutcome of this discussion should be tracked in a decision recorddiscussionDiscussions related to the design, implementation and operation of the projectDiscussions related to the design, implementation and operation of the projectdocumentationDocumentation of the project as well as procedural documentationDocumentation of the project as well as procedural documentation
Milestone
Description
Metadata
Metadata
Assignees
Labels
decision recordOutcome of this discussion should be tracked in a decision recordOutcome of this discussion should be tracked in a decision recorddiscussionDiscussions related to the design, implementation and operation of the projectDiscussions related to the design, implementation and operation of the projectdocumentationDocumentation of the project as well as procedural documentationDocumentation of the project as well as procedural documentation
Should we create classes for dictionary attributes of inner metadata classes (Targets/Snapshot/Timestamp/Root)?
Con: Seems a bit over-engineered, removes the light-footedness that comes with Python dictionaries
Pro: Makes our use of OOP more consistent.
Why would we use classes for Metadata/Signed/Targets/Snapshot, etc. but not for the inner dicts? (see #1112)
Pro: Makes it easier to validate formats, if complex data structures are defined by classes and simple data types use type annotations. (see #1130)