Re: HELP: renames and enum values

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

Al Johnston wrote:
> 
> Sorry... I should have said it... "without using a USE"...
> and without referencing EU_AGETDsc...

These seem bizare restrictions. Could you elaborate on the
context which is forcing such a straight-jacket upon you.

> 
> I really cant make since of this behavior...  I should be
> able to say something like
> sk_types.dsc.overrd0state_typ.override_off;
> 
> What I really want here is a rename of a data type,
> which doesn't seem to be available in ada...  I am
> trying to "isolate" one group of routines that use
> overrd0state_typ form another group of routines
> that use it... I know that is NOT subtypes are for,
> but they are the only thing (i have found so far) that
> might allow me to do this....  oh well..

A derived type will redefine all the literals.
They can be freely type converted between the
two types if interoperability is needed.
Why are derived types not applicable?
The degree of separation between these two
groups of routines seems to indicate the need
for derived types to insure no accidental
mixing of the routines is coded.

> 
> So... any way to do this other than with a use/ref
> to original package??

You can define a bunch of enumeration constants
which are initialized to their corresponding
literals from the original package. This does
require references to the original package.
If such references are not pleasant given your
content, then perhaps you can use deferred constant.
The initializations, and their references to the
original package, will then be in the package
specification's private part.

> 
> thanks for the help... At least the language's behavior
> makes a little more since to me now.

To give you more than you probably wanted, one reason
subtypes do not redefine the literals is that enumeration
literals are semantically identical to parameterless functions.
This allows the same literal to be used in two different
enumeration types via the usually function overloading rules.
This also precludes redefining the literals in subtypes
because this would create duplicate homographs (two
subprograms in the same declarative region with the same
parameter profile and return types).

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"