From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00ff2b882a06fda X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: HELP: renames and enum values Date: 2000/04/10 Message-ID: <38F20A7C.3DCD5122@Raytheon.com>#1/1 X-Deja-AN: 609173617 Content-Transfer-Encoding: 7bit References: <38ECE0EB.4BD4A53E@mindspring.com> <38EE2019.4C91075D@Raytheon.com> <38EE494D.DDB9CE9@mindspring.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Aerospace Engineering Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-04-10T00:00:00+00:00 List-Id: 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!"