Re: "shadow" package hierarchy using renaming of child packages

[Adam Beneschan <adam@irvine.com>]

On Sunday, June 30, 2013 10:46:24 PM UTC-7, J-P. Rosen wrote:

> 10.1.1(13): The parent unit of a library_item shall be a library package
> or generic library package
> 
> ... and not a library_package_renaming_declaration

Also, 10.1.1(15) is more explicit, I think: "A parent_unit_name (which can be used within a defining_program_unit_name of a library_item and in the separate clause of a subunit), and each of its prefixes, shall not denote a renaming_declaration."  The name following the word "package" is a defining_program_unit_name, therefore any ancestor unit name that's part of the defining_program_unit_name can't be a renaming unit.

I don't think it's an arbitrary restriction, either.  Child units are able to directly access names defined in their ancestor units.  If we were able to write

   package A.B.C renames X.Y.Z;
  
   package A.B.C.D is ...

A.B.C.D would have direct visibility to names declared in its ancestors--but what are its ancestors?  A and A.B, or X and X.Y?  Keep in mind that the ancestor A.B.C is a rename of X.Y.Z and the specification of X.Y.Z will be able to directly refer to names in X and X.Y.  I think that allowing A.B.C.D here would lead to a big semantic mess.

                             -- Adam