> > Now one could consider creating a super-package containing all the parent
> > packages, but that would change all points of usage -- something I would not
> > think desirable.
> Any existing points of usage would indeed be impacted (as would the new
> child packages themselves) -- future points would not, by definition.
> Is this really true? Is it not the case that a simple library unit that
> renames the library unit that has become a child of a super package back
> to its old name would save any external clients ("packages outside the
> CSC") from changing? Consider e.g. a package Exported_Interface in the
> CSC. It would become "package CSC.Exported_Interface". This package
> could however be renamed back! "with CSC.Exported_Interface; package
> Exported_Interface renames CSC.Exported_Interface;"
Ok, that's even better: when there are pre-existing clients of the
refactored CSC, this renaming strategy permits them to remain intact!
More aggressive refactoring (perhaps as a later step) could, if desired,
remove those renamings and modify the clients to not need them. So, to
summarize the process steps discussed thus far:
1. Massage the original Ada83 code until it compiles as Ada95.
2. Refactor only the CSC code (as described), and provide renamings that
preserve its original interface.
3. Remove the renamings and adjust all client references to the new CSC.
> Internally to the CSC it is perhaps harder to get away without changes.
> When I tried the operation in ObjectAda with a non-exported package it
> said that I cannot rename it back to its original name. I guess that was
> to be expected.
I would hope that Ada95 won't allow a public renaming for a private
child! This has the added benefit that recompilation (after step 2) will
expose any existing client that bypasses the CSC interface to WITH an
internal spec. (NOTE: this could only occur if the original development
had progressed without the benefit of an environment feature such as
"export sets", thus enabling the undesired WITHing to occur -- I have
seen this problem many times.)
C. Daniel Cooper ==========v=================v=======================v
Adv Computing Technologist | processes | All opinions are mine |
206-655-3519 | + architectures | and may not represent |
[log in to unmask] | = systems | those of my employer. |