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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bc745b8412f53f25
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2004-03-01 15:21:26 PST
Path: 
 archiver1.google.com!news2.google.com!news.maxwell.syr.edu!border1.nntp.ash.giganews.com!border2.nntp.ash.giganews.com!nntp.giganews.com!elnk-atl-nf1!elnk-nf2-pas!elnk-pas-nf1!newsfeed.earthlink.net!sn-xit-02!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Error-names.
Date: Mon, 1 Mar 2004 17:20:51 -0600
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <1047hbljcig7912@corp.supernews.com>
References: <qrf6h1-mt1.ln1@martinkl.dialup.fu-berlin.de>
 <404178F0.67730051@sympatico.ca>
 <er19h1-f51.ln1@martinkl.dialup.fu-berlin.de>
 <404243E5.376C42BB@sympatico.ca>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Complaints-To: abuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:5989
Date: 2004-03-01T17:20:51-06:00
List-Id: <comp.lang.ada>

"David Marceau" <davidmarceau@sympatico.ca> wrote in message
news:404243E5.376C42BB@sympatico.ca...
...
> Now focus on what it should look like in Ada:
>
> procedure setParametersForServiceX
> (
> OLEORWINDOWSORJNIHANDLEOFSOMESORT
> , ObjectToWorkOn
> , ObjectHoldingParametersToPassToObjectToWorkOn
> );
>
> procedure callServiceX
> (
> OLEORWINDOWSORJNIHANDLEOFSOMESORT
> , ObjectToWorkOn
> );
>
> My variable names and declarations are not Ada standard or C standard but
what's
> important is the placement of parameters and the number of parameters in
the
> service calling pattern to facilitate long term maintenance.  The rule of
thumb
> is there should be no more than three parameters in
setParametersForService and
> no more than two parameters in callService.
...
> I'd love to hear what others think about this.  I'm all ears.

In Ada 95, I don't think this is a great idea, because you lose the
advantages of default parameters. We thought about this a lot in the context
of Claw, and decided having separate parameters was better, because they
could have appropriate defaults, and thus you rarely need to give them.
Moreover, you can add parameters to a routine without changing any calls
simply by giving appropriate defaults to new parameters.

None of this is possible with records, because the aggregates need to be
complete. So if you add a new item, you'll get errors on all of the calls,
even if the new item is relatively unimportant.

For instance, a Claw window create routine could look like:

     procedure Create (Window : in out Window_Type;
                                   Parent : in out Root_Window_Type'Class;
                                   Position : in Point_Type :=
Use_Default_Position;
                                   Size : in Size_Type := Use_Default_Size;
                                   Menu : in Menu_Type := No_Menu;
                                   Title : in String := "";
                                   Show_System_Menu : in Boolean := True;
                                   Show_Close_Box : in Boolean := True;
                                   Allow_Resizing : in Boolean := True;
                                   ...
                                   );

A call could look like:

    Create (New_Window, My_Parent, Size => (100, 100));

While a call using a record would have to give all of the parameters
(components). Yuck.

Ada 200Y will fix this, as there is a way to initialize record components to
defaults:

     (Size => (100, 100), others => <>);

so your technique will work better in the future. But note that it still
won't work well with indefinite parameters (like the Title parameter above).

                         Randy.