TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Robert I. Eachus" <[log in to unmask]>
Reply To:
Robert I. Eachus
Date:
Thu, 15 Oct 1998 12:10:37 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
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...

ATOM RSS1 RSS2