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/
next prev 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