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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9d8db3defac005a2
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-11-23 07:48:16 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Newsgroups: comp.lang.ada
Subject: Re: Renaming an abstract function
Date: 23 Nov 2001 10:40:02 -0500
Organization: NASA Goddard Space Flight Center
Message-ID: <uwv0hlcml.fsf@gsfc.nasa.gov>
References: <9t1lp1$16unne$1@ID-25716.news.dfncis.de>
 <uvggau5ro.fsf@gsfc.nasa.gov>
 <b4682ab7.0111161908.1d330e1@posting.google.com> <3BF6DE1F.6C31A357@home.com>
 <uherqbwj3.fsf@gsfc.nasa.gov> <9tht9c$2j1ni$2@ID-25716.news.dfncis.de>
NNTP-Posting-Host: anarres.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: skates.gsfc.nasa.gov 1006530174 13707 128.183.220.71 (23 Nov 2001
 15:42:54 GMT)
X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov
NNTP-Posting-Date: 23 Nov 2001 15:42:54 GMT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Xref: archiver1.google.com comp.lang.ada:16908
Date: 2001-11-23T15:42:54+00:00
List-Id: <comp.lang.ada>

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> > ...
> > Well, the full text of the AI talks about renaming an _inherited_
> > subprogram, not the abstract subprogram itself. It does not discuss
> > exactly what should happen for this case.
> 
> Precisely my point (in parallel post).
> 
> > Simply following the rules for inheriting abstract subprograms, you
> > are required to give an overriding subprogram for any derived type.
> > Thus, if the renaming is valid, you'd have to override both P and "*",
> 
> This is correct.
> 
> > which is surely not the intent.
> 
> Yes it is the intent. The Rationale (8.3) makes this clear.

Well, I meant the "intent of the programmer". If I rename a function,
I "intend" to have two names for one function. If, when deriving the
type, I must provide _two_ functions, that is not two names for _one_
function. Of course, I can provide the same function, but I'd prefer
the language to enforce it.

Rationale 8.3 does say the behavior of renamed primitive operations
"may be considered surprising". I guess that's all I'm saying; I find
the behavior of inherited renamed primitive operations surprising. But
having read the Rationale (something I should do more often), I can
see why it has to be this way.

> > So it seems reasonable to conclude that the renaming itself is
> > invalid.
> 
> No, I don't think so.

Right, this is pretty close to the example in the rationale.

> > We could propose a "renaming inheritance" rule that says an
> > equivalent renaming is applied to the overriding subprogram; that
> > is the intent of this renaming.
> 
> Intriguing idea, but it is already laid down: the renaming creates a new
> 'slot', thus both (the original and renamed) subprograms can be (and, in the
> case of an asbtract subprogram, would need to be) overridden separately.

Yes, but the Rationale doesn't specifically address inheriting a
renamed function. It would be good if it did.

-- 
-- Stephe