* Question about enumeration types @ 2001-07-24 11:40 Reinert Korsnes 2001-07-24 12:23 ` Larry Hazel ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Reinert Korsnes @ 2001-07-24 11:40 UTC (permalink / raw) Hi, (sorry for somehow repeating a question) Given the program as below. Here I did put "E : E1" inside a record since "E" is also a possible value for the enumeration type E1. This is somehow verbose. Is it a more elegant way ? I find it boring that extending the range of possible values of an enumeration type may easily cause conflicts with variable names, and new variable names may cause conflicts values for enumeration types. I sometimes would like to have the reserved word "Exit" as a possible value of an enumeration type.... Am I thinking somewhat wrong ? reinert with Text_IO; use Text_IO; procedure Atest1 is type E1 is (A, B, C, D, E); package E1_Io is new Text_IO.Enumeration_Io (E1); use E1_Io; -- this conflicts with "E" as a possible value for type "E1" -- E : E1; type ARec_t is record E : E1; end record; ARec : ARec_t; begin ARec.E := A; Put(E1'First);Put(" ");Put(E1'Last); end Atest1; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about enumeration types 2001-07-24 11:40 Question about enumeration types Reinert Korsnes @ 2001-07-24 12:23 ` Larry Hazel 2001-07-24 12:31 ` Marc A. Criley 2001-07-26 16:52 ` Robert Dewar 2 siblings, 0 replies; 6+ messages in thread From: Larry Hazel @ 2001-07-24 12:23 UTC (permalink / raw) Reinert Korsnes wrote: > > Hi, > > (sorry for somehow repeating a question) > > Given the program as below. Here I did put "E : E1" inside > a record since "E" is also a possible value for the enumeration type E1. > > This is somehow verbose. Is it a more elegant way ? There is no conflict here. You must always reference a record component this way. I think any other way would be less elegant. > I find it boring that extending the range of possible values of > an enumeration type may easily cause conflicts with variable names, > and new variable names may cause conflicts values for enumeration > types. I sometimes would like to have the reserved word "Exit" > as a possible value of an enumeration type.... Am I thinking > somewhat wrong ? At least an Ada compile will tell you about conflicts. You can't use reserved words for anything else. I have also wanted to use Exit at times, but settled for Quit or Stop or some such. Range is another reserved word that would be the best variable name in some cases. You just have to qualify it in some way - Maximum_Range for instance. Larry ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about enumeration types 2001-07-24 11:40 Question about enumeration types Reinert Korsnes 2001-07-24 12:23 ` Larry Hazel @ 2001-07-24 12:31 ` Marc A. Criley 2001-07-26 16:52 ` Robert Dewar 2 siblings, 0 replies; 6+ messages in thread From: Marc A. Criley @ 2001-07-24 12:31 UTC (permalink / raw) Reinert Korsnes wrote: > > Hi, > > (sorry for somehow repeating a question) > > Given the program as below. Here I did put "E : E1" inside > a record since "E" is also a possible value for the enumeration type E1. > > This is somehow verbose. Is it a more elegant way ? > > I find it boring that extending the range of possible values of > an enumeration type may easily cause conflicts with variable names, > and new variable names may cause conflicts values for enumeration > types. I sometimes would like to have the reserved word "Exit" > as a possible value of an enumeration type.... Am I thinking > somewhat wrong ? Well, if you add a variable name, a type name, a procedure name, etc., you also have to worry about about causing conflicts with existing variable, type, procedure, etc., names that have the same visibility, so there's nothing particularly different about adding enumeration literals. One technique I've seen used is to prefix each enumeration literal with its type name or some other convention. For your example: type E1 is (E1_A, E1_B, E1_C, E1_D, E1_E); Now you can add E1_Exit with no problem. Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about enumeration types 2001-07-24 11:40 Question about enumeration types Reinert Korsnes 2001-07-24 12:23 ` Larry Hazel 2001-07-24 12:31 ` Marc A. Criley @ 2001-07-26 16:52 ` Robert Dewar 2001-07-27 13:04 ` Ken Garlington 2001-07-31 9:59 ` Peter Hermann 2 siblings, 2 replies; 6+ messages in thread From: Robert Dewar @ 2001-07-26 16:52 UTC (permalink / raw) Reinert Korsnes <Reinert.Korsnes@ffi.no> wrote in message news:<3B5D5EA5.F20EC9D7@ffi.no>... > I find it boring that extending the range of possible values of > an enumeration type may easily cause conflicts with variable names, Let me assume you mean tedious here instead of boring. Well yes, it is part of the Ada design to favor the reader over the writer of code. Under certain circumstances, the compiler could use type information to disambiguate: type r is (a,b,c); c : integer; Now if we see: x(c); then by looking at x we *may* be able to tell which was intended. But the attempt is illegal. Why? Because it's confusing to reader of the code to have names reused in this manner. Furthermore, obviously it does not generally work, since type r is (a,b,c); c : r; obviously cannot work, so you have to suffer some of the tediousness anyway. It's really FAR better not to casually reuse names. Sure, if you are in an intelligent editor environment, e.g. GLIDE on GNAT, you can click and find out what's what, but you are not always in such an environment, and it's still a distraction. The writer of the code has the job of finding good unambiguous, unique names for all entities. You may find it tedious/boring to do this task properly, but the maintainence programmers down the road will thank you for your extra effort, and the Ada language design will to the extent possible force you to do your job properly :-) Now you may ask why allow overloading at all? That's a reasonable question, the answer is that overloading can help readability *IF* the subprograms with the same name have the same abstract purpose. So if we see Put (r); we expect that it does the same logical thing as all other versions of Put, e.g. output an ASCII representation of r on the standard output file (more accurately the current output file). Now if you have a program where you have two functions procedure Arguement (F : Func); -- Supply saved argument for function F procedure Argument (W : Employee); -- Record that employee W got into an argument with management That's bad programming, because the two procedures have nothing to do with one another at an abstract level, and now the prograqm is harder to read, because the reader will not know which version of Argument is the appropriate one. Unfortunately the compiler has no way of treating this horrible misuse of overloading as an error, so you don't get any diagnostic in this case. One may also raise the question of whether it is a good thing at a more global level to have the same name mean different things in different parts of the program, and where possible, this should be avoided. In GNAT, there is a warning flag -gnatwh that flags all cases of declarations hiding other declarations of the same name. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about enumeration types 2001-07-26 16:52 ` Robert Dewar @ 2001-07-27 13:04 ` Ken Garlington 2001-07-31 9:59 ` Peter Hermann 1 sibling, 0 replies; 6+ messages in thread From: Ken Garlington @ 2001-07-27 13:04 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0107260852.2dcba52a@posting.google.com... : Now if you have a program where you have two functions : : procedure Arguement (F : Func); : -- Supply saved argument for function F : : procedure Argument (W : Employee); : -- Record that employee W got into an argument with management : : That's bad programming, because the two procedures have nothing to : do with one another at an abstract level, and now the prograqm is : harder to read, because the reader will not know which version of : Argument is the appropriate one. Unfortunately the compiler has no : way of treating this horrible misuse of overloading as an error, : so you don't get any diagnostic in this case. What overloading? I don't see anything overloaded here! :) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about enumeration types 2001-07-26 16:52 ` Robert Dewar 2001-07-27 13:04 ` Ken Garlington @ 2001-07-31 9:59 ` Peter Hermann 1 sibling, 0 replies; 6+ messages in thread From: Peter Hermann @ 2001-07-31 9:59 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> wrote: > Reinert Korsnes <Reinert.Korsnes@ffi.no> wrote in message news:<3B5D5EA5.F20EC9D7@ffi.no>... >> I find it boring that extending the range of possible values of >> an enumeration type may easily cause conflicts with variable names, > Let me assume you mean tedious here instead of boring. > Well yes, it is part of the Ada design to favor the reader over the ^^^^^^^^^^^ > writer of code. Under certain circumstances, the compiler could use > type information to disambiguate: > type r is (a,b,c); > c : integer; [snipp] I have to thank Robert Dewar for spending his time for giving a useful elaborated lecture on this subject, which BTW is the answer for my casecrash problem some days ago. Convincing. My thanks to Tucker Taft, too. comp.lang.ada seems to be a precious source, indeed. (sometimes...) -- Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen http://www.csv.ica.uni-stuttgart.de/homes/ph/ Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-07-31 9:59 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-24 11:40 Question about enumeration types Reinert Korsnes 2001-07-24 12:23 ` Larry Hazel 2001-07-24 12:31 ` Marc A. Criley 2001-07-26 16:52 ` Robert Dewar 2001-07-27 13:04 ` Ken Garlington 2001-07-31 9:59 ` Peter Hermann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox