Define that package.order requires a package - #3928
Conversation
…should be stored as package.mo.
|
|
||
| In order to preserve the order of classes and constants, it is advisable to create a file \filename{package.order}\index{package.order@\filename{package.order}} where each line contains the name of one class or constant (using its Modelica \lstinline!IDENT! form). | ||
| If a \filename{package.order} is present when reading a directory, the classes and constants are added in this order; if the contents does not exactly match the classes and constants in the package, the resulting order is tool specific and a warning may be given. | ||
| In order to preserve the order of classes and constants in package, it is advisable to create a file \filename{package.order}\index{package.order@\filename{package.order}} where each line contains the name of one class or constant (using its Modelica \lstinline!IDENT! form). |
There was a problem hiding this comment.
| In order to preserve the order of classes and constants in package, it is advisable to create a file \filename{package.order}\index{package.order@\filename{package.order}} where each line contains the name of one class or constant (using its Modelica \lstinline!IDENT! form). | |
| In order to preserve the order of classes and constants in a package, it is advisable to create a file \filename{package.order}\index{package.order@\filename{package.order}} where each line contains the name of one class or constant (using its Modelica \lstinline!IDENT! form). |
I can see that it would be an inconsistency to allow package.mo for a class where it is not allowed to have a corresponding package.order. However, I think there are good use cases also for storing non-packages in a directory with one or more .mo files inside:
Edit: @maltelenz just pointed out that https://specification.modelica.org/master/packages.html#external-resources speaks of package name, so I am striking out the item about regarding external resources attached to non-packages. |
| By construction, a directory (e.g., the directory \filename{P}) which is part of a stored hierarchy will contain the file \filename{package.mo}. | ||
| This file shall contain a \productionref{stored-definition}, defining a single class (possibly with nested classes inside). | ||
| The name of the class (here, \lstinline!P!) shall match the name of the directory. | ||
| The class should be a package. |
There was a problem hiding this comment.
As long as there are good use cases also for non-packages, I don't think we should use strong recommendations like this. A weaker non-normative comment would be more suitable, but if it is only a weak recommendation I am not sure it belongs in the specification at all.
There was a problem hiding this comment.
A non-normative replacement has now been suggested below.
| The class should be a package. |
|
|
||
| \begin{nonnormative} | ||
| The \filename{package.mo} typically contains documentation and graphical information for a package, but may also contain additional elements of the class \lstinline!P!. | ||
| \end{nonnormative} |
There was a problem hiding this comment.
Alternative to the above:
| Typically, the class defined in \filename{package.mo} will be a package, but there are also situations where classes of other specializations may benefit from being stored as a directory with a \filename{package.mo} inside. | |
| \end{nonnormative} |
| In order to preserve the order of classes and constants, it is advisable to create a file \filename{package.order}\index{package.order@\filename{package.order}} where each line contains the name of one class or constant (using its Modelica \lstinline!IDENT! form). | ||
| If a \filename{package.order} is present when reading a directory, the classes and constants are added in this order; if the contents does not exactly match the classes and constants in the package, the resulting order is tool specific and a warning may be given. | ||
| In order to preserve the order of classes and constants in package, it is advisable to create a file \filename{package.order}\index{package.order@\filename{package.order}} where each line contains the name of one class or constant (using its Modelica \lstinline!IDENT! form). | ||
| If a \filename{package.order} is present when reading a directory for a package, the classes and constants are added in this order; if the contents does not exactly match the classes and constants in the package, the resulting order is tool specific and a warning may be given. |
There was a problem hiding this comment.
Don't we want to be more restrictive and actually ban the presence of package.order for non-packages?
There was a problem hiding this comment.
If we allow a directory structure for non package classes, probably also a package.order file is needed for that.
There was a problem hiding this comment.
The current support for package constants is of course easy to generalize to non-constant components, but the whole point of this PR is that the package.order idea is too difficult to apply to classes with equations.
henrikt-ma
left a comment
henrikt-ma
left a comment
There was a problem hiding this comment.
More discussion is needed regarding the status of package.mo for non-packages.
4 participants
and that only packages should be stored as package.mo.
Closes #3921
Note: I generalized it to require that even package.mo should (so, there might be exceptions) be a package. We might revisit that, but I think it is a good general rule.
I agree that having package.order for a non-package would be really problematic - as there are non-constants, equations etc that must be ordered.
Having package.mo for a non-package would to me only make sense for a top-level class where you want to store resources as if it were a package, and in that case having sub-classes (and especially sub-classes stored externally) doesn't really make sense.