Re: Smart Pointers and Tagged Type Hierarchies

[Felix Krause <contact@flyx.org>]

On 2017-07-24 21:24:58 +0000, Chris Moore said:

>> * 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).

Well, if the smart pointer for File_Stream is the same type as the 
smart pointer for Stream, I'd need to downcast the retrieved access 
type each time I want to call a subroutine only defined for 
File_Stream, such as Current_Position in my example. An explicit 
downcast is undesirable because it implies that it may fail, which it 
cannot when I create a File_Stream reference with a construction 
subroutine and subsequently call Current_Position on it.

> 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.

The sad thing is that I really like the prefix notation, which drags me 
towards tagged types, even though I don't like dispatching that much. 
Also, controlled types are tagged types, so it is hard to avoid them.

-- 
Regards,
Felix Krause