TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version: 1.0
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: "Robert I. Eachus" <[log in to unmask]>
Date: Thu, 15 Oct 1998 12:10:37 -0400
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"
Reply-To: "Robert I. Eachus" <[log in to unmask]>
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