At 09:22 PM 10/14/98 GMT, Matthew Heaney wrote:
>Although I'm generally happy with Ada95, I feel that not requiring
>programmers to explicitly state that an operation overrides that of its
>parent, is a language flaw.

   Personally I don't think it is.  But the easiest solution to this
problem is in the hands of the compiler vendors.  It is not unusual for a
(non-overriding) operation to have a different parameter and result profile:

    function Create return Foo;
    ...
    type Foobar is new Foo with Bar;
    function Create(B: in Bar) return Foobar;

   It is not unusual for a non-overriding operation to be declared where it
won't be inherited, although you often want to use 'Class in such cases.

   with Lists;
   ...
   procudure Foob(A: Anything; L: in Lists.List...);

   But it is unusual for a non-overriding inheritable operation to be
declared with the same parameter and result profile as an inherited
operation that is not overrriden, especially if the two have similar names.
 So in such cases, a compiler can print a warning.  A warning which did no
comparisions on names would probably be a bit much, but one that just
checked for the same initial letter would be right more often than wrong,
and I'm sure that compiler writers can come up with better criteria.

  In fact, there is another closely related anomaly that existed in Ada 83
that I think compilers should warn about, since is much more likely in Ada 95:

  type Foo is ...;
  function Get return Foo;

  type Bar is new Foo;
  function Get(From: Ada.Text_IO.File_Type := Ada.Text_IO.Current_Input)
                return Bar;

  B: Bar := Get; -- ambiguous
  C: Bar := Bar'(Get); -- still ambiguous!

  The derived Get can't be called, but it prevents the new Get from being
called using the defaults.  Take out the default, or better:

  type Bar is new Foo;

  function Get return Bar;
  function Get(From: Ada.Text_IO.File_Type) return Bar;
  ...
  function Get return Bar is begin return Get(Ada.Text_IO.Current_Input); end;

  Gives the originally intended effect. Again, an intelligible warning will
allow the progammer to fix the problem and proceed onward.  Waiting until
the point of call doesn't help.  This is a mistake on the part of the
person writing the package, not the caller of the package.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...