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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!cs.uu.nl!news.stack.nl!aioe.org!.POSTED!not-for-mail
From: Victor Porton <porton@narod.ru>
Newsgroups: comp.lang.ada
Subject: Re: abstract types and subprograms
Date: Tue, 20 May 2014 15:28:29 +0300
Organization: Aioe.org NNTP Server
Message-ID: <llfhpb$ka4$1@speranza.aioe.org>
References: <llfad4$he$1@speranza.aioe.org>
 <7puqh5yz4dyf.pov2dgfr2ky$.dlg@40tude.net>
NNTP-Posting-Host: LRua1LhEwYx/r1KnMXeYtA.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: abuse@aioe.org
User-Agent: KNode/4.12.4
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:19928
Date: 2014-05-20T15:28:29+03:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:

> On Tue, 20 May 2014 13:22:30 +0300, Victor Porton wrote:
> 
>> By the philosophy of programming From_Handle should be non-abstract but
>> return an abstract object, and From_Handle should be automatically
>> overridden for descendants non-abstract objects.
>> 
>> What is wrong?
> 
> You cannot automatically override without knowing the implementation,
> which you don't in advance. If you know it, then it is same for all class.
> See below.
> 
>> -- rdf-base.ads
>> with Ada.Finalization;
>> with Interfaces.C.Pointers;
>> 
>> package RDF.Base is
>> 
>>    -- Internal
>>    type Dummy_Record is null record;
>> 
>>    -- Internal
>>    type Dummy_Record_Access is access Dummy_Record;
>>    
>>    type Base_Object is abstract new Ada.Finalization.Limited_Controlled
>>    with
>> private;
>>    
>>    function Get_Handle(Object: Base_Object) return Dummy_Record_Access
>>    with
>> Inline;
>>    
>>    function From_Handle(Handle: Dummy_Record_Access) return Base_Object
>>    with
>> Inline;
> 
> function From_Handle(Handle: Dummy_Record_Access) return
> Base_Object'Class;
> 
> Logically, a handle can point on an object of any type derived from
> Base_Object, so it is a class.

But can this:

   function From_Handle(Handle: Dummy_Record_Access) return Base_Object is
      (Ada.Finalization.Limited_Controlled with Handle=>Handle);

be implemented if the return type changes to Base_Object'Class?

It seems for me that I should define it as above and override From_Handle 
for each derived tagged type.

It seems that returning Base_Object'Class wouldn't magically make it work 
(without explicit override).

Or can it be done implementing Frorm_Handle only once (for Base_Object) with 
automatic changing its signature for derived tagged types?

-- 
Victor Porton - http://portonvictor.org