From: "Nick Roberts" <nickroberts@adaos.worldonline.co.uk>
Subject: Re: Renaming an abstract function
Date: Sat, 17 Nov 2001 23:17:29 -0000
Date: 2001-11-17T23:17:29+00:00 [thread overview]
Message-ID: <9t6sro$nbro$2@ID-25716.news.dfncis.de> (raw)
In-Reply-To: 3BF6DE1F.6C31A357@home.com
"Mark Biggar" <mark.a.biggar@home.com> wrote in message
news:3BF6DE1F.6C31A357@home.com...
> ...
> There is an AI that addresses this problem:
[AI95-211]
> ...
> >An abstract subprogram can be renamed, and the renamed view is also
> >abstract. Such a renaming must appear in a place where the declaration
> >of an abstract subprogram would be legal. Similarly, the "shall be
>overridden"
> >property of 3.9.3(6) applies to a renamed view. Thus, any renaming of an
> >inherited subprogram that must be overridden is illegal.
Many thanks for pointing out this AI, Mark.
> This explains the compilation error as the renaming "*" is a must be
> overridden function as it has an abstract return type and thus is
> illegal.
I don't think the AI explains it at all, in fact. The renaming of "*" in my
example is not attempting to rename an inherited subprogram. The type T is a
root abstract type (not derived from anything), so the functions P and "*"
are not inherited.
--
Best wishes,
Nick Roberts
next prev parent reply other threads:[~2001-11-17 23:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-15 23:52 Renaming an abstract function Nick Roberts
2001-11-16 14:52 ` Stephen Leake
2001-11-17 3:08 ` Adam Beneschan
2001-11-17 17:47 ` Egil Harald Hoevik
2001-11-17 18:33 ` Stephen Leake
2001-11-17 22:00 ` Mark Biggar
2001-11-17 23:17 ` Nick Roberts [this message]
2001-11-19 15:38 ` Stephen Leake
2001-11-22 3:14 ` Nick Roberts
2001-11-23 15:40 ` Stephen Leake
2001-11-24 3:55 ` Nick Roberts
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox