* Re: HELP: renames and enum values [not found] <38ECE0EB.4BD4A53E@mindspring.com> @ 2000-04-07 0:00 ` Samuel T. Harris 2000-04-07 0:00 ` Al Johnston 2000-04-11 0:00 ` Tucker Taft 1 sibling, 1 reply; 19+ messages in thread From: Samuel T. Harris @ 2000-04-07 0:00 UTC (permalink / raw) Al Johnston wrote: > > I am having a little trouble with the following: > > package EU_AG.ET.Dsc is > > type OvrRd0State_Typ is (OVERRIDE_OFF,OVERRIDE_ON); > for OvrRd0State_Typ'size use integer'size; > for OvrRd0State_Typ use (OVERRIDE_OFF => 0,OVERRIDE_ON => 1); > end EU_AG.ET.Dsc; > > with EU_AG.ET.Dsc; > package SK_Types.Dsc is > package EU_AGETDsc renames EU_AG.ET.Dsc; > subtype OvrRd0State_Typ is EU_AGETDsc.OvrRd0State_Typ; > end SK_Types.Dsc; > > with SK_Types.Dsc; > package THREE is > foo : SK_Types.Dsc.OvrRd0State_Typ := SK_Types.Dsc.OVERRIDE_OFF; > end THREE; > > When I compile "THREE" the compiler complains that "OVERRIDE_OFF" is not > > declared in "Dsc". I could get around this by renaming each of the enum > values > (that is adding OVERRIDE _OFF renames EU_AG.ET.Dsc.OVERRIDE_OFF; > to the sk_types.dsc package spec,) but that would be pretty nasty for a > large > enum type... plus the fact that it totally defeats the point of package > in the first place. > > Any one know of a better way of doing the reference to OVERRIDE_OFF in > the package THREE? > > thanks, > > -al Type OvrRd0State_Typ is a subtype. Subtypes do not propogate new definitions for the enumeration literals. The literals remain defined within package EU_AG.ET.Dsc. A derived type would create new and visible enumeration literals but I assume you don't want a derived type here. Since package SK_Types.Dsc renames package EU_AG.ET.Dsc as package EU_AGETDsc and package three only withs SK_Types.Dsc and does not with EU_AG.ET.Dsc I assume you want a solution which does not introduce a new with clause. Within package three, you can add 'use EU_AGETDsc;' which will makes the enumeration literals visible. So you would have ... with SK_Types.Dsc; package THREE is use SK_Types.Dsc.EU_AGETDsc; foo : SK_Types.Dsc.OvrRd0State_Typ := SK_Types.Dsc.OVERRIDE_OFF; end THREE; So you actually were very nearly there :) -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-07 0:00 ` HELP: renames and enum values Samuel T. Harris @ 2000-04-07 0:00 ` Al Johnston 2000-04-09 0:00 ` Robert Dewar 2000-04-10 0:00 ` Samuel T. Harris 0 siblings, 2 replies; 19+ messages in thread From: Al Johnston @ 2000-04-07 0:00 UTC (permalink / raw) Sorry... I should have said it... "without using a USE"... and without referencing EU_AGETDsc... 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.. So... any way to do this other than with a use/ref to original package?? thanks for the help... At least the language's behavior makes a little more since to me now. -al ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-07 0:00 ` Al Johnston @ 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` dale ` (2 more replies) 2000-04-10 0:00 ` Samuel T. Harris 1 sibling, 3 replies; 19+ messages in thread From: Robert Dewar @ 2000-04-09 0:00 UTC (permalink / raw) In article <38EE494D.DDB9CE9@mindspring.com>, Al Johnston <sofeise@mindspring.com> wrote: > What I really want here is a rename of a data type, > which doesn't seem to be available in ada... subtype x is y; why isn't that good enough for renaming purposes???? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-09 0:00 ` Robert Dewar @ 2000-04-09 0:00 ` dale 2000-04-09 0:00 ` Robert Dewar 2000-04-10 0:00 ` Samuel T. Harris 2000-04-11 0:00 ` Al Johnston 2 siblings, 1 reply; 19+ messages in thread From: dale @ 2000-04-09 0:00 UTC (permalink / raw) Robert Dewar wrote: > subtype x is y; > > why isn't that good enough for renaming purposes???? ...because beginners don't think of it? Is there any reason why it shouldn't work? (apart from being another way to accomplish the same thing), i.e. is there some fundamental philosoply embedded in Ada that means it would be a Bad Thing? Dale ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-09 0:00 ` dale @ 2000-04-09 0:00 ` Robert Dewar 2000-04-10 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 19+ messages in thread From: Robert Dewar @ 2000-04-09 0:00 UTC (permalink / raw) In article <dale-F87224.15225009042000@news.rmit.edu.au>, dale <dale@cs.rmit.edu.au> wrote: > Robert Dewar wrote: > > > subtype x is y; > > > > why isn't that good enough for renaming purposes???? > > ...because beginners don't think of it? > > Is there any reason why it shouldn't work? (apart from being another > way to accomplish the same thing), i.e. is there some fundamental > philosoply embedded in Ada that means it would be a Bad Thing? Sorry, I don't know what you mean by "another way" here, this is the ONE and ONLY method to get the effect of "renaming" types, and is absolutely standard Ada, and yes it works fine. And who knows what beginners might or might not think of, but any decent Ada book should point out this standard usage. The RM of course is quite clear on the semantic effect of such a declaration, and that's the end of its responsibility, the RM gives the (fairly) formal definition of the language, it is not in the business of pointing out how it can be used :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-09 0:00 ` Robert Dewar @ 2000-04-10 0:00 ` Dale Stanbrough 2000-04-13 0:00 ` John English 0 siblings, 1 reply; 19+ messages in thread From: Dale Stanbrough @ 2000-04-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > Sorry, I don't know what you mean by "another way" here, this > is the ONE and ONLY method to get the effect of "renaming" > types, and is absolutely standard Ada, and yes it works fine. > > And who knows what beginners might or might not think of, but > any decent Ada book should point out this standard usage. The > RM of course is quite clear on the semantic effect of such > a declaration, and that's the end of its responsibility, the > RM gives the (fairly) formal definition of the language, it is > not in the business of pointing out how it can be used :-) > All i was attempting to say is that type blah renames bleh; could be predicted to have the same semantics as a subtype declaration (this would be the "other way" of performing subtyping). I know what beginners think of, because I had 8 years of teaching beginners. This is something that some of them thought of (but not many because most of them were introduced to subtypes long before renames!). I do understand the use of subtype, but I was just wondering if there were some fundamental reason why a renames for a type would be excluded (apart from not wanting two ways to do the same thing). Dale ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-10 0:00 ` Dale Stanbrough @ 2000-04-13 0:00 ` John English 2000-04-13 0:00 ` Samuel T. Harris ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: John English @ 2000-04-13 0:00 UTC (permalink / raw) Dale Stanbrough wrote: > All i was attempting to say is that > > type blah renames bleh; > > could be predicted to have the same semantics as a subtype > declaration (this would be the "other way" of performing > subtyping). > > I know what beginners think of, because I had 8 years of > teaching beginners. This is something that some of them > thought of (but not many because most of them were introduced > to subtypes long before renames!). What's even less obvious is the way to rename enumeration literals: function Enum_Literal return Enum_Type renames Other_Enum_Literal; Now, that *really* confuses them, and none of them would ever be able to guess it without being told! ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` John English @ 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Ted Dennison ` (2 subsequent siblings) 3 siblings, 0 replies; 19+ messages in thread From: Samuel T. Harris @ 2000-04-13 0:00 UTC (permalink / raw) John English wrote: > > Dale Stanbrough wrote: > > All i was attempting to say is that > > > > type blah renames bleh; > > > > could be predicted to have the same semantics as a subtype > > declaration (this would be the "other way" of performing > > subtyping). > > > > I know what beginners think of, because I had 8 years of > > teaching beginners. This is something that some of them > > thought of (but not many because most of them were introduced > > to subtypes long before renames!). > > What's even less obvious is the way to rename enumeration literals: > > function Enum_Literal return Enum_Type renames Other_Enum_Literal; > > Now, that *really* confuses them, and none of them would ever be > able to guess it without being told! > Perhaps I am not "one of them" since I figured this out quickly the first time I ran into this renaming problem way back in my youth. I learned Ada 83 by reading the reference manual long before I had a compiler to play with. During my initial reading, I found it strange that enumeration literals would be defined as parameterless functions. A little introspection quickly revealed the necessity of this semantic definition to allow the same literal to be used in different enumeration type definitions. When I later actually had a compiler to use and needed to rename some enumeration literals, the function renames was the first thing I thought of. I actually did not expect the compiler to accept it, figuring the semantic definition was just some standarized sugar but was pleasantly surprise with the successful results. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` John English 2000-04-13 0:00 ` Samuel T. Harris @ 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Robert A Duff 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Robert Dewar 2000-04-14 0:00 ` Tucker Taft 3 siblings, 2 replies; 19+ messages in thread From: Ted Dennison @ 2000-04-13 0:00 UTC (permalink / raw) In article <38F5D6F9.5B8892F2@bton.ac.uk>, John English <je@bton.ac.uk> wrote: > Dale Stanbrough wrote: > > All i was attempting to say is that > > > > type blah renames bleh; > > > > could be predicted to have the same semantics as a subtype > > declaration (this would be the "other way" of performing > > subtyping). > > > > I know what beginners think of, because I had 8 years of > > teaching beginners. This is something that some of them > > thought of (but not many because most of them were introduced > > to subtypes long before renames!). > > What's even less obvious is the way to rename enumeration literals: > > function Enum_Literal return Enum_Type renames Other_Enum_Literal; > > Now, that *really* confuses them, and none of them would ever be > able to guess it without being told! What's wrong with: Enum_Literal : constant Enum_Type := Other_Enum_Literal; ? -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` Ted Dennison @ 2000-04-13 0:00 ` Robert A Duff 2000-04-13 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 19+ messages in thread From: Robert A Duff @ 2000-04-13 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > What's wrong with: > Enum_Literal : constant Enum_Type := Other_Enum_Literal; > > ? You lose the ability to overload the literals. - Bob ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Robert A Duff @ 2000-04-13 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 19+ messages in thread From: Samuel T. Harris @ 2000-04-13 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <38F5D6F9.5B8892F2@bton.ac.uk>, > John English <je@bton.ac.uk> wrote: > > Dale Stanbrough wrote: > > > All i was attempting to say is that > > > > > > type blah renames bleh; > > > > > > could be predicted to have the same semantics as a subtype > > > declaration (this would be the "other way" of performing > > > subtyping). > > > > > > I know what beginners think of, because I had 8 years of > > > teaching beginners. This is something that some of them > > > thought of (but not many because most of them were introduced > > > to subtypes long before renames!). > > > > What's even less obvious is the way to rename enumeration literals: > > > > function Enum_Literal return Enum_Type renames Other_Enum_Literal; > > > > Now, that *really* confuses them, and none of them would ever be > > able to guess it without being told! > > What's wrong with: > Enum_Literal : constant Enum_Type := Other_Enum_Literal; > package a is type x is (one, two, three); type y is (one, two, three); end a; with a; package b is function one return a.x renames a.one; function two return a.x renames a.two; function three return a.x renames a.three; function one return a.y renames a.one; function two return a.y renames a.two; function three return a.y renames a.three; end b; with a; package c is one : constant a.x := a.one; two : constant a.x := a.two; three : constant a.x := a.three; one : constant a.y := a.one; -- compilation error two : constant a.y := a.two; -- compilation error three : constant a.y := a.three; -- compilation error -- these are co-resident homographs. end c; As I alluded to in a previous post, enumeration literals are semantically defined as parameter-less functions. This allows overloading them in different enumeration type definitions. This also them multiple renames because the correct renaming is a parameter-less function renames declaration. Constants cannot be overloaded! However, constants usually fill the bill in my actual experience since overloaded enumeration literals simply don't come up often in those rare cases where I need to redefine the things. I say rare cases because there are many other ways to get the adequate results that I simply don't need to rename enumeration literals anymore. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` John English 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Ted Dennison @ 2000-04-13 0:00 ` Robert Dewar 2000-04-14 0:00 ` John English 2000-04-14 0:00 ` Tucker Taft 3 siblings, 1 reply; 19+ messages in thread From: Robert Dewar @ 2000-04-13 0:00 UTC (permalink / raw) In article <38F5D6F9.5B8892F2@bton.ac.uk>, John English <je@bton.ac.uk> wrote: > function Enum_Literal return Enum_Type renames Other_Enum_Literal; > > Now, that *really* confuses them, and none of them would ever be > able to guess it without being told! I have a different view of learning languages, I do not expect my students to "guess" anything about a language, I expect them to learn rules and apply them. I agree that this rule might be non-intuitive if the basic semantics of enumeration literals has not been presented in a clear manner. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` Robert Dewar @ 2000-04-14 0:00 ` John English 0 siblings, 0 replies; 19+ messages in thread From: John English @ 2000-04-14 0:00 UTC (permalink / raw) Robert Dewar wrote: > In article <38F5D6F9.5B8892F2@bton.ac.uk>, > John English <je@bton.ac.uk> wrote: > > function Enum_Literal return Enum_Type renames > Other_Enum_Literal; > > > > Now, that *really* confuses them, and none of them would ever > be > > able to guess it without being told! > > I have a different view of learning languages, I do not expect > my students to "guess" anything about a language, I expect them > to learn rules and apply them. > > I agree that this rule might be non-intuitive if the basic > semantics of enumeration literals has not been presented in > a clear manner. Well, this is not quite what I meant; *if* they had to guess it, they wouldn't in a million years. I don't expect my students to guess things either, and I do indeed explain it, but in my experience many students find it completely unintuitive that the literals of a type are actually functions, and it takes a bit of frowning and head-scratching before they finally write it off as "hey, it's crazy, but you gotta live with it". ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.comp.it.bton.ac.uk/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-13 0:00 ` John English ` (2 preceding siblings ...) 2000-04-13 0:00 ` Robert Dewar @ 2000-04-14 0:00 ` Tucker Taft 3 siblings, 0 replies; 19+ messages in thread From: Tucker Taft @ 2000-04-14 0:00 UTC (permalink / raw) John English wrote: > ... > > What's even less obvious is the way to rename enumeration literals: > > function Enum_Literal return Enum_Type renames Other_Enum_Literal; > > Now, that *really* confuses them, and none of them would ever be > able to guess it without being told! We sort of fixed this in Ada 95. In Ada 83, if you did the "obvious" thing: Enum_Literal : Enum_Type renames Other_Enum_Literal; you got your hand slapped by the compiler because it is attempting to rename a value as an object. In Ada 95, the above is perfectly legal, and I would expect most people to use it for renaming. The only reason *not* to use the "obvious" renaming is if you want the renaming itself to be overloadable. That seems relatively less common. If you are sophisticated enough to want to have your renamings overloadable, then you are probably sophisticated enough to use function renamings to accomplish them. So I would not consider this a teaching problem any more. The beginning user can do the obvious thing, and the more sophisticated user can get overloadability if they need it. > > ----------------------------------------------------------------- > John English | mailto:je@brighton.ac.uk > Senior Lecturer | http://www.it.bton.ac.uk/staff/je > Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** > University of Brighton | -- see http://burks.bton.ac.uk > ----------------------------------------------------------------- -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` dale @ 2000-04-10 0:00 ` Samuel T. Harris 2000-04-11 0:00 ` Al Johnston 2 siblings, 0 replies; 19+ messages in thread From: Samuel T. Harris @ 2000-04-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <38EE494D.DDB9CE9@mindspring.com>, > Al Johnston <sofeise@mindspring.com> wrote: > > > What I really want here is a rename of a data type, > > which doesn't seem to be available in ada... > > subtype x is y; > > why isn't that good enough for renaming purposes???? > > Sent via Deja.com http://www.deja.com/ > Before you buy. It really doesn't rename the type. Enumeration literals are not available from the subtype. When I do a package rename, I can reference all the package content from the renamed package. So subtyping is related, but not the same, as renaming. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` dale 2000-04-10 0:00 ` Samuel T. Harris @ 2000-04-11 0:00 ` Al Johnston 2 siblings, 0 replies; 19+ messages in thread From: Al Johnston @ 2000-04-11 0:00 UTC (permalink / raw) > > What I really want here is a rename of a data type, > > which doesn't seem to be available in ada... > > subtype x is y; > > why isn't that good enough for renaming purposes???? S Harris gave the "correct" answer to why the above is not correct (I started this thread, so I get to say what is correct with respect to my intent). He said: >It really doesn't rename the type. >Enumeration literals are not available from >the subtype. To get to the values associated with subtype "x" you still have to reference type "y". This defeats the whole point of doing the "rename" (implemented as a subtype). -al ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-07 0:00 ` Al Johnston 2000-04-09 0:00 ` Robert Dewar @ 2000-04-10 0:00 ` Samuel T. Harris 2000-04-11 0:00 ` Al Johnston 1 sibling, 1 reply; 19+ messages in thread From: Samuel T. Harris @ 2000-04-10 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values 2000-04-10 0:00 ` Samuel T. Harris @ 2000-04-11 0:00 ` Al Johnston 0 siblings, 0 replies; 19+ messages in thread From: Al Johnston @ 2000-04-11 0:00 UTC (permalink / raw) > > > 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 am to "smart" (I hope) to start this thread... the debate over using "use". And in this case I can avoid it. The code I am reworking has the same type declared in multiple places. I am reworking the code to get ride of them. Avoiding the use of use helps me catch the errors I make... leaving/using the use would mask many of the errors until a later change. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HELP: renames and enum values [not found] <38ECE0EB.4BD4A53E@mindspring.com> 2000-04-07 0:00 ` HELP: renames and enum values Samuel T. Harris @ 2000-04-11 0:00 ` Tucker Taft 1 sibling, 0 replies; 19+ messages in thread From: Tucker Taft @ 2000-04-11 0:00 UTC (permalink / raw) Al Johnston wrote: > > I am having a little trouble with the following: > > package EU_AG.ET.Dsc is > > type OvrRd0State_Typ is (OVERRIDE_OFF,OVERRIDE_ON); > for OvrRd0State_Typ'size use integer'size; > for OvrRd0State_Typ use (OVERRIDE_OFF => 0,OVERRIDE_ON => 1); > end EU_AG.ET.Dsc; > > with EU_AG.ET.Dsc; > package SK_Types.Dsc is > package EU_AGETDsc renames EU_AG.ET.Dsc; > subtype OvrRd0State_Typ is EU_AGETDsc.OvrRd0State_Typ; > end SK_Types.Dsc; > > with SK_Types.Dsc; > package THREE is > foo : SK_Types.Dsc.OvrRd0State_Typ := SK_Types.Dsc.OVERRIDE_OFF; > end THREE; > > When I compile "THREE" the compiler complains that "OVERRIDE_OFF" is not > > declared in "Dsc". I could get around this by renaming each of the enum > values > (that is adding OVERRIDE _OFF renames EU_AG.ET.Dsc.OVERRIDE_OFF; > to the sk_types.dsc package spec,) but that would be pretty nasty for a > large > enum type... plus the fact that it totally defeats the point of package > in the first place. > > Any one know of a better way of doing the reference to OVERRIDE_OFF in > the package THREE? One way would be to move the enumeration type declaration into a subpackage all by itself. You could then rename this subpackage rather than the enumeration type itself, and all references to the enumeration type and the enumeration literals would uniformly use the subpackage name as a prefix. > thanks, > > -al -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2000-04-14 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <38ECE0EB.4BD4A53E@mindspring.com> 2000-04-07 0:00 ` HELP: renames and enum values Samuel T. Harris 2000-04-07 0:00 ` Al Johnston 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` dale 2000-04-09 0:00 ` Robert Dewar 2000-04-10 0:00 ` Dale Stanbrough 2000-04-13 0:00 ` John English 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Robert A Duff 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Robert Dewar 2000-04-14 0:00 ` John English 2000-04-14 0:00 ` Tucker Taft 2000-04-10 0:00 ` Samuel T. Harris 2000-04-11 0:00 ` Al Johnston 2000-04-10 0:00 ` Samuel T. Harris 2000-04-11 0:00 ` Al Johnston 2000-04-11 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox