Skip to content

Avoid speaking of file system entities#3924

Open
henrikt-ma wants to merge 1 commit into
modelica:masterfrom
henrikt-ma:cleanup/no-filesystem-entities
Open

Avoid speaking of file system entities#3924
henrikt-ma wants to merge 1 commit into
modelica:masterfrom
henrikt-ma:cleanup/no-filesystem-entities

Conversation

@henrikt-ma

Copy link
Copy Markdown
Collaborator

This PR improves the File System Mapping of Package/Class section by avoiding introduction of the various "entity" terms. Instead, the new presentation is focused around the well known concepts of files and directories, with the addition of stored hierarchy for the part of the whole file system hierarchy that corresponds to a Modelica class.

This PR is meant to replace #3890, applying the idea that the language group agreed upon in #3890 (comment).

@henrikt-ma henrikt-ma force-pushed the cleanup/no-filesystem-entities branch from 5a73a5a to 1050016 Compare June 24, 2026 11:36
Comment thread chapters/packages.tex

\begin{nonnormative}
A non-empty \lstinline!within!-clause only states redundant information, completely determined by the file location in the stored hierarchy rooted in the directory where the \filename{package.mo} has no or an empty \lstinline!within!-clause.
The redundant information is not only a convenience for tools and humans, it is also information needed to verify that \lstinline!Protection!-annotations (\Cref{modelica:Protection.access}) are not bypassed by moving an encrypted file to a different location in the class tree.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The redundant information is not only a convenience for tools and humans, it is also information needed to verify that \lstinline!Protection!-annotations (\Cref{modelica:Protection.access}) are not bypassed by moving an encrypted file to a different location in the class tree.

We have currently not defined whether encrypted files can be stored hierarchically, and I could see several issues with that (including the within-issues - but also other ones) that I don't think we should just add it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants