Re: Question about enumeration types

[dewar@gnat.com (Robert Dewar)]

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.