From f89c0c2c87790843394df4487dc166e30fe95a45 Mon Sep 17 00:00:00 2001 From: Henrik Tidefelt Date: Wed, 24 Jun 2026 10:07:41 +0200 Subject: [PATCH 1/3] Clarify that package.order does not affect visibility --- chapters/packages.tex | 3 +++ 1 file changed, 3 insertions(+) diff --git a/chapters/packages.tex b/chapters/packages.tex index 2527a52e1..edaec320d 100644 --- a/chapters/packages.tex +++ b/chapters/packages.tex @@ -226,6 +226,9 @@ \subsection{Directory Hierarchy Mapping}\label{mapping-a-package-class-hierarchy If a \filename{package.order} is present when reading a structured entity 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. Classes and constants that are stored in \filename{package.mo} are also present in \filename{package.order} but their relative order should be identical to the one in \filename{package.mo} (this ensures that the relative order between classes and constants stored in different ways is preserved). +Only elements defined in \filename{package.mo} are affected by the visibility control (\cref{access-control-public-and-protected-elements}) in \filename{package.mo}; the child classes defined in other files or directories always have public visibility. +In particular, reordering classes using \filename{package.order} has no impact on visibility. + \subsection{Single File Mapping}\label{mapping-a-package-class-hierarchy-into-a-single-file-nonstructured-entity}\label{single-file-mapping} From 5f2aaf7971033bda20803e3685adbbeb117081f1 Mon Sep 17 00:00:00 2001 From: Henrik Tidefelt Date: Fri, 3 Jul 2026 00:07:03 +0200 Subject: [PATCH 2/3] Clarify and cross-reference --- chapters/classes.tex | 4 ++-- chapters/packages.tex | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/chapters/classes.tex b/chapters/classes.tex index f7a9a2cf5..a3b7ccbfa 100644 --- a/chapters/classes.tex +++ b/chapters/classes.tex @@ -41,8 +41,8 @@ \section{Access Control -- Public and Protected Elements}\label{access-control-p \end{lstlisting} \end{example} -All elements defined under the heading \lstinline!protected! are regarded as protected. -All other elements (i.e., defined under the heading \lstinline!public!, without headings or in a separate file) are public (i.e., not protected). +The visibility headings \lstinline!protected! and \lstinline!public! determine the visibility of subsequent elements on the same level defined in the same file, until the next visibility heading. +Elements before the first visibility heading and elements defined in different files (see \cref{directory-hierarchy-mapping}) have public visbility. Regarding inheritance of protected and public elements, see \cref{inheritance-of-protected-and-public-elements}. diff --git a/chapters/packages.tex b/chapters/packages.tex index edaec320d..2e9926c7a 100644 --- a/chapters/packages.tex +++ b/chapters/packages.tex @@ -226,8 +226,9 @@ \subsection{Directory Hierarchy Mapping}\label{mapping-a-package-class-hierarchy If a \filename{package.order} is present when reading a structured entity 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. Classes and constants that are stored in \filename{package.mo} are also present in \filename{package.order} but their relative order should be identical to the one in \filename{package.mo} (this ensures that the relative order between classes and constants stored in different ways is preserved). -Only elements defined in \filename{package.mo} are affected by the visibility control (\cref{access-control-public-and-protected-elements}) in \filename{package.mo}; the child classes defined in other files or directories always have public visibility. +As defined in \cref{access-control-public-and-protected-elements}, the effect of the visibility headings \lstinline!public! and \lstinline!protected! appearing in \filename{package.mo} only affect visibility of elements defined in that file; the child classes defined in other files or directories always have public visibility. In particular, reordering classes using \filename{package.order} has no impact on visibility. +It also follows that an element which is a class can neither be mapped to a file nor a directory; it must be directly present in the same file as its parent class. \subsection{Single File Mapping}\label{mapping-a-package-class-hierarchy-into-a-single-file-nonstructured-entity}\label{single-file-mapping} From 39117bac3f26b14bbfbccb3ed16b28e85154c44e Mon Sep 17 00:00:00 2001 From: Henrik Tidefelt Date: Fri, 3 Jul 2026 08:46:33 +0200 Subject: [PATCH 3/3] Fix "an element" -> "a protected element" --- chapters/packages.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/packages.tex b/chapters/packages.tex index 2e9926c7a..68e1fa348 100644 --- a/chapters/packages.tex +++ b/chapters/packages.tex @@ -228,7 +228,7 @@ \subsection{Directory Hierarchy Mapping}\label{mapping-a-package-class-hierarchy As defined in \cref{access-control-public-and-protected-elements}, the effect of the visibility headings \lstinline!public! and \lstinline!protected! appearing in \filename{package.mo} only affect visibility of elements defined in that file; the child classes defined in other files or directories always have public visibility. In particular, reordering classes using \filename{package.order} has no impact on visibility. -It also follows that an element which is a class can neither be mapped to a file nor a directory; it must be directly present in the same file as its parent class. +It also follows that a protected element which is a class can neither be mapped to a file nor a directory; it must be directly present in the same file as its parent class. \subsection{Single File Mapping}\label{mapping-a-package-class-hierarchy-into-a-single-file-nonstructured-entity}\label{single-file-mapping}