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=-0.3 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC,T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac5c3bc59168d76 X-Google-Attributes: gid103376,public From: johndoe (johndoe) Subject: Re: Subprogram Renaming Date: 1996/04/10 Message-ID: X-Deja-AN: 146636673 sender: johndoe@dsd.camb x-nntp-posting-host: dsd.camb.inmet.com references: organization: Intermetrics, Inc., Cambridge, MA reply-to: johndoe@inmet.com (Bus error - core dumped) newsgroups: comp.lang.ada Date: 1996-04-10T00:00:00+00:00 List-Id: 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" 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/