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=3.1 required=5.0 tests=BAYES_00,FILL_THIS_FORM_LOAN,
	INVALID_MSGID,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,896d86ef3723978c
X-Google-Attributes: gid103376,public
From: "John G. Volan" <johnv@ac3i.dseg.ti.com>
Subject: Re: maintenance of overriding subprograms
Date: 1997/09/04
Message-ID: <340F5B87.80B@ac3i.dseg.ti.com>#1/1
X-Deja-AN: 269917634
References: <340C2EA5.B9F@gsfc.nasa.gov> <340DCE1D.6C5F@bix.com>
Organization: Raytheon TI Systems
Reply-To: johnv@ac3i.dseg.ti.com
Newsgroups: comp.lang.ada
Date: 1997-09-04T00:00:00+00:00
List-Id: <comp.lang.ada>


Tom Moran wrote:
> 
> A related error, not, unfortunately, solved by that syntax occurs when a
> maintainer erroneously believes some parameter to have a default, and
> accordingly removes or comments it out in a call, eg
>   package Basic is
>     type Object_Type is tagged ...
>     procedure Create_Object(X : Object_Type;
>         Name : in String; Size, Position : in Rectangles);
> ...
>   package Fancy is
>     type Fancy_Object_Type is new Basic.Object_Type with ...
>     procedure Create_Object(X : Fancy_Object_Type;
>         Name : in String; Size, Position : in Rectangles;
>         Title : in String);
> ...
> A call
>   Create_Object(X -- X is a Fancy_Object
>      "It's name", The_Size, The_Position, "");
> is erroneously changed to
>   Create_Object(X -- X is a Fancy_Object
>      "It's name", The_Size, The_Position);
> under the misapprehension that Title defaults to the null string.  But
> in fact this has changed from a call on Fancy.Create to an inherited
> call on Basic.Create  Manual proofreading of the code is fairly likely
> to miss the error, but what's especially insidious is that the behavior
> is probably quite similar, so the fact there is a problem may not show
> up for some time.

    package Basic is
    
You can avoid this sort of thing by adopting the following practices:

(1)  Give controlling subprogram parameters names that reflect their
level of abstraction. Don't use an "inherited" identifier.  e.g.:

  package Basic is
    type Basic_Object_Type is tagged ...
    procedure Create
      (Basic_Object    : in out Basic_Object_Type; 
        Name           : in     String;
        Size, Position : in     Rectangle_Type);
...
  package Fancy is
    type Fancy_Object_Type is new Basic.Basic_Object_Type with ...
    procedure Create
      (Fancy_Object   : in out Fancy_Object_Type; 
       Name           : in     String;
       Size, Position : in     Rectangle_Type;
       Title          : in     String);
...

(2) Use named parameter association syntax religiously, e.g.:

  Fancy.Create 
    (Fancy_Object => Your_Fancy_Object -- _obviously_ a Fancy_Object
     Name         => "It's name", 
     Size         => The_Size,
     Position     => The_Position,
     Title        => "");

If you then try to change it to:

  Fancy.Create 
    (Fancy_Object => Your_Fancy_Object -- _obviously_ a Fancy_Object
     Name         => "It's name", 
     Size         => The_Size,
     Position     => The_Position);

then you get a compilation error.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------