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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	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: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Subprogram Renaming
Date: 1996/04/10
Message-ID: <dewar.829163957@schonberg>#1/1
X-Deja-AN: 146856994
references: <md5:95D854EBD1A47E0E86027A3CC7DBD9A4>
 <316BC3D6.14E7@csehp3.mdc.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-04-10T00:00:00+00:00
List-Id: <comp.lang.ada>

James Squire asks

"2.  Once again, the real question is:  why do I need an explicit body
for j when I can rename k in the spec of q?  That has been my question
all along."

That's very easy to answer (and to my reading has been answerd several
times already in this thread).

YOu put something in the spec if it is part of the specification. One
can imagine cases where it is part of the spec that A renames B, as for
example when you deliberately have two names for the identical same
operation.

But if the renaming is essentailly just a choice of how a particular
function is implemented then it is a serious violation of the abstraction
to expose the renaming.

For example, it a package providing set abstractions, I would not like
to see:

  Is_Member (E : Element; S : Set) return Boolean
     renames Binary_Tree_Ops.Test_Item_Present;

since it is none of my business that at the moment sets are implemented
using the binary tree package.