comp.lang.ada
 help / color / mirror / Atom feed
From: johndoe (johndoe)
Subject: Re: Subprogram Renaming
Date: 1996/04/10
Date: 1996-04-10T00:00:00+00:00	[thread overview]
Message-ID: <kdd95h53l3.fsf@dsd.camb> (raw)
In-Reply-To: md5:FE4AB546A8392541EDC1E3FE12E3D8AF

i'll answer:  but i want to know how you're going to get me my $64,000...

In article <316AEA8D.7600@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes:
>Still (!) Nobody has answered the $64,000.00 question:  WHY IS THIS SUCH
>A GOOD THING?  In other words, why did they waste their time adding this
>ability to rename a subprogram body. 
>Why should I do:			>when I can do:         
>					>                       
>package q is				>package q is           
>  procedure j;				>  procedure k;         
>end q;					>end q;                 
>					>                       
>package body q is			>package body q is      
>  procedure k;				>  procedure k is ...   
>  procedure j renames k;		>end q;                 
>end q;

well, there probably isn't a good reason for you to do what you have on the
left above.  however, that is not exactly what was shown in the articles you
quoted.

the point primarily addresses the case where "k" comes from a different
package.  in that case, what you're saying is basically that the
"implementation" of "k" is exactly that of "j".  why put lines in j that just
call k when the syntax is there (at least in ada95) to have any call to k
just be routed to j's code.

1) for certain operations, it may be desirable to use a rename

   take
	package F is
	   subtype Unsigned_int is Interfaces.C.Unsigned_Int;
	   function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int;
	end F;

   then
	package body F is
	    function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int
	      renames Interfaces.C."+";
	end F;

   requires a "use F;" clause "use type F.Unsigned_Int"; in comparison not
   having "+" in the spec requires a separate "use" for Interfaces.C; and
   not using the renames requires a body for "+" that is basically extra
   code.

2) in cases where you are attempting to create a package that only has
   certain operations in the spec, you may find it desirable to completely
   implement one of those operations by simply calling another.  if the
   subprogram parameter profile is identical, then using a renames saves
   code.  and you may not want all of the other functions to be visible
   from the package where you got your renamed subprogram.  in fact, they
   may even be private.

    private
    package A.Z is
	procedure M( X : Integer; Y : Boolean );
	procedure N( X : Integer );
    end A.Z;

    package A.Y is
	procedure Only_Visible( P : Integer; Q : Boolean );
    end A.Y;

    with A.Z.M;
    package body A.Y is
	procedure Only_Visible( P : Integer; Q : Boolean ) renames A.Z.M;
    end A.Y;

   in the above case, no one outside of the hierarchy of A is allowed to
   with A.Z .  but, since A.Z.M is exactly the same as A.Y.Only_Visible,
   why duplicate effort.

>Now that I KNOW I can do in Ada83.  Since the parameter spec has to
>match exactly, I see no point to doing a rename in the body and hiding
>it from the user.  All you are changing is the name it goes by.  What's
>the point?

well, depending on what you're referring to, your statement may actually be
wrong.  and it brings up the case where the parameter profile is the same
but the look of the spec is different.  take the following, which you can
presume to all be defined in the spec:

    procedure Create_Calculator_Button(
	Button : in out Xt.Intrinsic.Widget;
	Name : in Interfaces.C.Char_Array;
	Label : in X.Strings.Const_Charp;
	Foreground : access X.Xresource.XrmValue;
	Background : access X.Xresource.XrmValue;
	CBack : in Xt.Intrinsic.XtCallbackProc := Operation_Callback'ACCESS;
	Width : in Xt.Intrinsic.XtArgVal := 38;
	Height : in Xt.Intrinsic.XtArgVal := 30;
	Button_Font_Charp : in X.Strings.Const_Charp := Normal_Font_Charp)


    procedure Create_Digit_Button(
	Button : in out Xt.Intrinsic.Widget;
	Name : in Interfaces.C.Char_Array;
	Label : in X.Strings.Const_Charp;
	Foreground : access X.Xresource.XrmValue := X.Colors.Yellow'ACCESS;
	Background : access X.Xresource.XrmValue := X.Colors.Navy'ACCESS;
	CBack : in Xt.Intrinsic.XtCallbackProc := Input_Digit_callback'Access;
	Width : in Xt.Intrinsic.XtArgVal := 38;
	Height : in Xt.Intrinsic.XtArgVal := 30;
	Button_Font_Charp : in X.Strings.Const_Charp := Big_Font_Charp )
      renames Create_Calculator_Button;

    procedure Create_Operator_Button(
	Button : in out Xt.Intrinsic.Widget;
	Name : in Interfaces.C.Char_Array;
	Label : in X.Strings.Const_Charp;
	Foreground : access X.Xresource.XrmValue := X.Colors.White'ACCESS;
	Background : access X.Xresource.XrmValue := X.Colors.SteelBlue'ACCESS;
	CBack : in Xt.Intrinsic.XtCallbackProc := Operation_callback'Access;
	Width : in Xt.Intrinsic.XtArgVal := 38;
	Height : in Xt.Intrinsic.XtArgVal := 30;
	Button_Font_Charp : in X.Strings.Const_Charp := Big_Font_Charp )
      renames Create_Calculator_Button;

now, the code for the above is basically all the same.  but, since the last
two definitions have all those extra foreground and background defaults, and
since the Button_Font_Charp has changed for them from the original, it allows
much more terse call-site naming, while maintaining some uniformity amongst
buttons of the same ilk:

    Create_Operator_Button( Buttons(PLUS), "operatorPlus", Plus_charp );
    Create_Operator_Button( Buttons(MINUS), "operatorMinus", Minus_charp );
    Create_Operator_Button( Buttons(DIVIDE), "operatorDivide", Div_charp );
    Create_Operator_Button( Buttons(MULTIPLY), "operatorDivide", Mult_charp );
    Create_Digit_Button( Buttons('9'), "number9", Label => Nine_charp );
    Create_Digit_Button( Buttons('8'), "number8", Label => Eight_charp );
    Create_Digit_Button( Buttons('7'), "number7", Label => Seven_charp );
    Create_Digit_Button( Buttons('6'), "number6", Label => Six_charp );
    Create_Digit_Button( Buttons('5'), "number5", Label => Five_charp );
    Create_Digit_Button( Buttons('4'), "number4", Label => Four_charp );
    Create_Digit_Button( Buttons('3'), "number3", Label => Three_charp );
    Create_Digit_Button( Buttons('2'), "number2", Label => Two_charp );
    Create_Digit_Button( Buttons('1'), "number1", Label => One_charp );

    --| special size buttons, either vertically or horizontally
    Create_Digit_Button( Buttons('0'), "number0", Zero_Charp, Width=> 78 );

--johndoe@inmet.com--Kirk Beitz--VOX:(619)683-3337	--FAX(619)683-2121--
--http://www.inmet.com/~johndoe/




  parent reply	other threads:[~1996-04-10  0:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <md5:FE4AB546A8392541EDC1E3FE12E3D8AF>
1996-04-09  0:00 ` Subprogram Renaming James A. Squire
1996-04-09  0:00   ` Robert Dewar
1996-04-10  0:00   ` Robert A Duff
1996-04-11  0:00   ` Mark A Biggar
1996-04-10  0:00 ` johndoe [this message]
1996-04-10  0:00   ` Norman H. Cohen
1996-04-11  0:00     ` Norman H. Cohen
1996-04-12  0:00       ` Jonas Nygren
1996-04-12  0:00         ` Norman H. Cohen
1996-04-13  0:00           ` Robert A Duff
1996-04-15  0:00             ` Norman H. Cohen
     [not found] <md5:3CC2294B6049DDBD8790280EABCEDE81>
1996-04-12  0:00 ` James A. Squire
     [not found] <md5:95D854EBD1A47E0E86027A3CC7DBD9A4>
1996-04-10  0:00 ` johndoe
1996-04-10  0:00 ` James A. Squire
1996-04-10  0:00   ` Robert Dewar
1996-04-11  0:00     ` Jonas Nygren
1996-04-11  0:00       ` Robert Dewar
1996-04-12  0:00         ` Jonas Nygren
1996-04-10  0:00   ` Robert A Duff
1996-04-11  0:00     ` Adam Beneschan
1996-04-11  0:00       ` Robert A Duff
1996-04-11  0:00       ` Robert Dewar
     [not found] <md5:87494FB95037B9578F62831DE10B6BB3>
1996-04-10  0:00 ` James A. Squire
     [not found] <md5:88A5E8822105A2023A0A951BB5EC646E>
1996-04-10  0:00 ` James A. Squire
     [not found] <md5:046A59600C3FEFC327385C3E914D6997>
1996-04-08  0:00 ` James A. Squire
1996-04-08  0:00   ` Robert Dewar
1996-04-09  0:00     ` Gary McKee
1996-04-09  0:00   ` Robert A Duff
     [not found] <md5:C24D8C2EE138D9627FB8B93E2E35D9F3>
1996-04-05  0:00 ` James A. Squire
1996-04-06  0:00   ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox