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

Clarification parameter designation #27

Merged
merged 2 commits into from
Mar 15, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/5___ssd.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -339,6 +339,8 @@ The hierarchical names of the parameters or other variables of a system are form
{empty}[ _For example for a system A containing a system B which contains an exposed parameter named SP1 and an element C with a parameter P2, the hierarchical names of the parameters in system A are B.SP1 and B.C.P2 respectively.
The hierarchical name of those parameters inside system B are SP1 and C.P2 respectively._ ]

{empty}[ _For example, a parameter binding of a e.g. a component A which contains an exposed parameter P shall reference the parameter using its local name P, not the hierarchical name A.P (possibly after any mapping)._ ]
DagBruck marked this conversation as resolved.
Show resolved Hide resolved

Note that the hierarchical names of parameters or other variables do not have to be unique: If two or more variables end up with the same hierarchical name (due to so-called punning), then any parameter values being applied to that name *MUST* be applied to all of them.
If this is not wanted, then it is up to the generating implementation to ensure that no punning occurs, through proper choice of system and element names.

Expand Down
Loading