-
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
Define more annotations as declarations #3448
base: master
Are you sure you want to change the base?
Conversation
This seemingly opens up for expressions instead of the literals |
Good point, and the answer to the latter is it depends |
One possibility would be to change them to |
I have now included that definition.
Note in particular that the Figure-annotation isn't a parameter at all - since it directly refers to expressions for curves. (But the rest of it should likely be constant (or possibly parameter)). |
I would like some more input on this:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to be more careful to not overload parameter
and constant
with other than the usual meanings.
This doesn't mean that I'm pushing for having, say, more constant than "literal" variability, but overall I would actually expect it to be possible to ease up variability requirements in the future to have less ad-hoc requirements to only support constant expressions in the form of literals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main remaining question seems to be what we can really promise regarding the presentation of component declaration style annotations – for which there has to exist a default behavior.
Co-authored-by: Henrik Tidefelt <[email protected]>
chapters/annotations.tex
Outdated
@@ -584,7 +611,7 @@ \subsection{Connection Restrictions}\label{connection-restrictions} | |||
|
|||
A connector component declaration may have the following annotation: | |||
\begin{lstlisting}[language=modelica] | |||
annotation(mayOnlyConnectOnce = "message"); | |||
/*literal*/ constant String mayOnlyConnectOnce; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default can be expressed with declaration equation:
/*literal*/ constant String mayOnlyConnectOnce; | |
/*literal*/ constant String mayOnlyConnectOnce = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a string so false would be wrong. But could reformulate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a default and rephrased.
chapters/annotations.tex
Outdated
|
||
\subsection{Connection Restrictions}\label{connection-restrictions} | ||
|
||
A connector component declaration may have the following annotation: | ||
\begin{lstlisting}[language=modelica] | ||
annotation(mustBeConnected = "message"); | ||
/*literal*/ constant String mustBeConnected; | ||
\end{lstlisting}% | ||
\annotationindex{mustBeConnected} | ||
|
||
It makes it an error if the connector does not appear as an inside connector in any connect-equation (for a conditional connector this check is only active if the connector is enabled). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel we are ending up with a cumbersome notation if we always need to say that the annotation only has effect when present…
It makes it an error if the connector does not appear as an inside connector in any connect-equation (for a conditional connector this check is only active if the connector is enabled). | |
Only has effect when present, and makes it an error if the connector does not appear as an inside connector in any connect-equation (for a conditional connector this check is only active if the connector is enabled). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a default and rephrased.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After making a couple of suggestions about complying with the notation we set out to follow, I am questioning the style we set for the default of component style annotations.
I think the default looks a lot like what one should write for making use of the annotation, which gets really confusing, especially for all the Boolean
ones, where it looks as if one should specify the opposite of what the name suggests unless one pays attention to the text.
Take singleInstance
for example. When looking at the synopsis, I see two things: the name singleInstance
, and the value false
. What I would like to see immediately is what to write in order to get the effect which is the purpose of the annotation.
Right now I don't have any concrete suggestion for what we might do instead, but I'd like to discuss this before I do the work of making more suggestions about complying with the current notation rules.
(It is a pity that we require the annotations to actually carry a modification, as the value tends to just be annoying and confusing for Boolean annotations.)
Co-authored-by: Henrik Tidefelt <[email protected]>
Language group poll:
Anne (abstain), Henrik (abstain), Elena(1), Markus(1), Gerd(1), Dag(1), Hans (abstain). Update. |
This has now been updated based on descision. |
More consistent non-syntax variant of defining annotations, based on comments in #2999
Notes: