Re: Subprogram Renaming

["James A. Squire" <m193884@CSEHP3.MDC.COM>]

On Tue, 9 Apr 1996 10:22:47, Gary McKee <gmckee@CLOUDNINE.COM> wrote:

> The rationale given when this change was submitted to the requirements team
> was as follows:
>
> The avowed purpose of a package specification is to offer a 'contract' for
> delivery of software services as implemented by the package body. When a
> subprogram is implemented via a renaming of another subprogram (procedure j
> renames k;), the 'contract' is compromised because the implementation must
> be placed in the specification. This is contrary to the paradigms of
> 'modularity, abstraction, and information hiding'.

OK.  I can see in some cases where this 'contract' is actually useful.
Of course, the only implementation that is being put into the spec is
the actual name and location of the implementation.  Every thing else is
interface details which are supposed to be public.  Frankly, I've seen
worse cases than subprogram specs as far as breaking modularity,
abstraction, and information hiding, which are allowed by both Ada83 and
Ada95, such as defining a variable (already a no-no in my book) by
renaming a function call.

What I see is that if you rename a subprogram from another package in
your package spec, then you have to with in the other package in the
spec, which means that potentially the other package spec can have an
affect on the user of your package, which you may not want.

Of course, if you really don't want the user to pay any attention to the
other package, you should make the other package a private child of your
package, at which point Ada95 requires you to rename your public
subprogram as the body of a subprogram in that private child.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"