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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7dfca01aeef9a8c0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-26 09:52:08 PST Path: archiver1.google.com!news2.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Question about enumeration types Date: 26 Jul 2001 09:52:07 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0107260852.2dcba52a@posting.google.com> References: <3B5D5EA5.F20EC9D7@ffi.no> NNTP-Posting-Host: 208.224.77.203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 996166327 23218 127.0.0.1 (26 Jul 2001 16:52:07 GMT) X-Complaints-To: groups-support@google.com NNTP-Posting-Date: 26 Jul 2001 16:52:07 GMT Xref: archiver1.google.com comp.lang.ada:10604 Date: 2001-07-26T16:52:07+00:00 List-Id: Reinert Korsnes 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.