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=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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Smart Pointers and Tagged Type Hierarchies
Date: Mon, 24 Jul 2017 21:53:54 +0200
Organization: Aioe.org NNTP Server
Message-ID: <ol5j8i$10s8$1@gioia.aioe.org>
References: <2017072417413775878-contact@flyx.org>
NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Language: en-US
Xref: news.eternal-september.org comp.lang.ada:47507
Date: 2017-07-24T21:53:54+02:00
List-Id: <comp.lang.ada>

On 2017-07-24 17:41, Felix Krause wrote:

> Now I am wondering what others think of these approaches. Are there 
> alternatives? Which one would be better from a user perspective?

I am using generic pointer (Handle), which can be instantiated later 
with any derived type from the base reference counting type. See Simple 
Components:

    http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc

This is your second approach but with object pointer type passed as a 
second generic parameter.

generic
    type Object_Type (<>) is abstract new Entity with private;
    type Object_Type_Ptr is access Object_Type'Class;
package Object.Handle is
    type Handle is new Ada.Finalization.Controlled with private;

Users of smart pointer need not to be generic. I don't know why you 
think it is necessary.

Regarding hierarchy of types and additional operations and the problem 
of exposing the implementation type. You can use delegation:

E.g. if you have your File_Stream_Object and File_Stream_Reference, you 
define a File_Stream_Interface:

    type File_Stream_Interface is interface;
    procedure Foo (Stream : in out File_Stream_Interface) is abstract;

Then both object and reference implement the interface:

    type File_Stream_Object is
       new Instance and File_Stream_Interface ...
    overriding procedure Foo (Stream : in out File_Stream_Reference);

    type File_Stream_Reference is
       new Reference and File_Stream_Interface ...
    overriding procedure Foo (Stream : in out File_Stream_Reference);

 From second Foo you call the first after dereferencing. Now you can 
hide File_Stream_Object and expose only File_Stream_Interface and 
File_Stream_Reference. You can also derive from File_Stream_Object and 
File_Stream_Reference adding new interfaces. The latter has a drawback 
that you will have to convert pointer to a more specific class.

------------------------------------
It is quite tedious because:

1. Delegation cannot be automated in Ada;
2. Pointer are not promoted upon inheritance.

Otherwise this schema works well.

If I were to propose new Ada features, which is of course would be 
pointless, I would solve #1 with providing access to interface 
implementation to generate wrappers:

    type File_Stream_Reference is
       new Reference
       and File_Stream_Interface ...;
private
    type File_Stream_Reference is
       new Reference
       and File_Stream_Interface ...
          with Implicit_Delegation => Data;

#2 could be solved by constraint propagation from Reference type to Data 
access member.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de