Clarify that package.order does not affect visibility

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}.
 
 

chapters/packages.tex

@@ -226,6 +226,10 @@ \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).
 
+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 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}