Re: Smart Pointers and Tagged Type Hierarchies

[Chris Moore <zmower@ntlworld.com>]

On 24/07/2017 16:41, Felix Krause wrote:
> With Ada's controlled types, it is possible to implement smart pointers 
> which manage heap objects with reference-counting. There is more than 
> one tutorial showing how that works.
> 
> A problem I encounter is how this can be used with type hierarchies i.e. 
> I have a smart pointer managing a tagged type, and I want to be able to 
> derive from that tagged type and still be able to use my smart pointer 
> with that new type. Let me give an example: Assume I want to implement 
> an abstract type Stream that represents a stream of events (has nothing 
> to do with Ada.Streams). I will use a slightly modified Rosen '95 name 
> scheme here for clarity: Reference is the smart pointer, Instance is the 
> actual object. Let this be the base type:
> 
<snip>
> 
> Some observations:
> 
> * Unless all implementations are child classes of Stream, it is 
> necessary to make the Instance type public.

Obv.

> * A derived type, if it wants to provide additional operations (like 
> Current_Position), must not only derive from Instance, but also from 
> Reference, to be able to provide an type-safe interface to those 
> operations.

Why?  All ops on Instance-derived types (including constructing 
subprograms) should be in terms of that type.  References are for access 
only (ho ho).

> * As types derived from Stream possibly need to derive Stream.Reference, 
> a consumer of a Stream object needs to take a Stream.Reference'Class as 
> input. This type cannot be used for a record field, so I need to 
> allocate it in heap memory and store a pointer if I want to memorize a 
> Stream.Reference value anywhere.

No.  This way lies madness.  A parallel hierarchy of References gains 
you very little and takes a lot of maintenance.

> * The implementation of Current_Position is cumbersome as I need the 
> Implementation_Access function and convert the result to 
> File_Stream.Instance, which creates a needless downcast check.

The downcast has to go *somewhere*.

<snip generic version>

I had to do this kind of thing a great deal in the Ada version of the 
mal lisp interpreter.  See for example:

https://github.com/zmower/mal/blob/master/ada/smart_pointers.ads
https://github.com/zmower/mal/blob/master/ada/types.ads

But my advice is to avoid tagged types if you can.  They only make sense 
if your problem is wildly dynamic or you want to be lazy when thinking 
about memory allocation.  mal qualified on both counts.