-
Notifications
You must be signed in to change notification settings - Fork 42
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
Make constants available to type definitions #2746
Conversation
In #2558 (comment), the following alternative solutions (here, cleaned up and renamed, but keeping original numbering) were proposed. Design alternativesOption 1: Global access to model constants
Pros:
Cons:
Option 2: All type definitions inside
|
Last comment on this matter in #2558 (comment) (omitting parts that are not relevant here): Web Meeting: Option 3 "Allow constants in global scope"
Option 2 "Package constant and record being defined inside model".
Mix of Option 2 and 3: "Allow constants in global scope and allow types in the model" |
Adding another design alternative according to previous comment: Option 7: Allow type definitions inside model and top level constant component definitionsThis design is a mix of option 2 and option 3, hence allowing for different uses. Done like option 2:
Done like option 3:
Pros:
Cons:
|
Web Meeting Hans: One could add: "package _dummy" if you don't want to change the parser. Martin: Why invent something new if it is not necessary. Kai: Why not make the parser broader and validate for the restricted case. This allows to generate better error messages. This is a good practice, not a bad design. Martin: We could agree to always create a package with a name of the model and name the model "Model". Henrik: It should be easy for users to agree on a common style of indentation. Hans: Why so concerned about generated Flat Modelica. Henrik: It's also about hand written code. Poll: Conclusion: Decision: Henrik: Will be good to find the name in the top node. Option 2: identical Option 3: empty Option 4: To Do: |
Let's also write down any drawbacks of this one (compared to option 2) next meeting:
|
I don't think we should more time on new proposals for that topic. |
This looks like the same kind of |
Web Meeting: fix line break and merge [Henrik] |
I think this must have been closed by mistake; it doesn't make sense in view of decision above. Reopening. |
I've corrected the mistakes on the branch now, but it seems like the Reopen and comment action with the comment above didn't work. Therefore, I'll just merge the branch and leave this PR in its strange closed state. |
Merging this branch according to decision in #2746 (comment). The PR has been closed, by mistake, I assume. Let's see what happens now to the state of the PR...
This PR breaks out the part of #2558 concerning the top level structure of a Flat Modelica description. The problem that needs to be solved is to make definitions of constants available to type definitions.