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

Reassess parametric design architecture for artifact attributes and functions #89

Open
DM1122 opened this issue May 30, 2022 · 0 comments
Assignees
Labels
architecture A change that involves a rearchitecture of the software exploratory An investigation of some sort that may or may not pan out into a feature
Milestone

Comments

@DM1122
Copy link
Collaborator

DM1122 commented May 30, 2022

Should a system be accessing the attributes of a component, and if that component does not have a value for that attribute, can it call a function to get that value?

Consider also the case the component has value, is its ability to recompute the attribute removed? What about conflicting values? I.e. a component is defined with attributes, but the function to compute a particular attribute returns a different value than the one that is defined. How to handle?

Or should every attribute that a system wants to extract from a component/subsystem be accessed with a "get_attribute()"?

How about placing a "if self.attribute exists, return the attribute" instead of computing the value? Or on init: self.attribute = attribute if it exists or else self.get_attribute

Some driving design factors

  • boilerplate in functions themselves should remain minimal to non-existent. There's a lot of functions, and any rearchitecting down the line would require all of the boilerplate changed.
  • Would be nice for systems to be able to just access attributes (res = self.component.resolution) instead of calling method (res = self.component.get_resolution()). If no boilerplate is allowed in the latter, there would never be a way for the actual attribute if it exists to be returned
@DM1122 DM1122 added the exploratory An investigation of some sort that may or may not pan out into a feature label May 30, 2022
@DM1122 DM1122 added this to the V1.0 milestone May 30, 2022
@DM1122 DM1122 self-assigned this May 30, 2022
@DM1122 DM1122 added the architecture A change that involves a rearchitecture of the software label May 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture A change that involves a rearchitecture of the software exploratory An investigation of some sort that may or may not pan out into a feature
Projects
None yet
Development

No branches or pull requests

1 participant