Re: Smart pointers and delegation

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-08-11 02:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:omh3iv$1flt$1@gioia.aioe.org...
>> On 2017-08-10 00:57, Randy Brukardt wrote:
> ...
>>> Even if true, the "real problem" however remains. If you can safely and
>>> efficiently copy the designated object, then you have no need for
>>> Implicit_Dereference. If you need "return-by-reference", though, you need
>>> some special mechanism to do that.
>>
>> I don't want
>>
>>     A (I) := X;
>>
>> taken literally. That is an abstraction inversion. I want it compiled into
>> more useful
>>
>>     Set (A, I, X);
> 
> But these are subtly different. The procedure form can only update the
> entire element at once. (Given the potentially large number of
> subcomponents, it would be impractical to implement a procedure for each
> one -- and if you want the compiler to do it, you'd have to be able to
> write - within the language - how that's done, which brings back the
> original question.)
> 
> Specifically, if you write:
>        A (I).C := Y;
> there isn't any translation using Set that would do the right thing. (Using
> an implicit temporary for the entire object would force extra copying, which
> would have performance and tasking implications - it would be outright wrong
> for volatile/atomic objects.)

This is why I am looking for delegation methods in order to route 
operation ".C :=" from element type to the container type:

    Set_C (A, I, Y);

This of course applies to all operations on container elements.

>> My design of containers is that I effectively put a reference in the form
>> of a smart pointer into the container. I don't need return by reference
>> because I return a smart pointer, which is definite and non-limited. I
>> have no problem with life time because the reference holds the object. I
>> less problems with concurrent updates because the reference has a count so
>> that the update may deploy a transaction scheme. And I tend to hide the
>> referenced object type from public interface to make it more safe.
> 
> Not sure I see how a "smart pointer" would work in this context. I could
> imagine some sort of handle working if you don't need partial, in-place
> updates.

Partial updates work because there an explicit operation to get plain 
access type:

    A (I).Ptr.C := Y; -- [*]

But I don't like this sort of things anyway. So usually it is a setter 
defined on the handle:

    A (I).Set_C (Y);

Which is why the handle and the target type implement same interface:

    type Element_Interface is interface;
    procedure Set_C (X : Element_Interface; Y : Integer);

And again I need delegation to automate trivial implementations of the 
interface:

    procedure Set_C (X : Handle; Y : Integer) is
    begin
       X.Ptr.Set_C (Y);
    end Set_C;

which presently I have to write manually.

-----------------------------
* I really do not understand why Implict_Dereference has this ugly form 
instead of simply declaring that type P is a user implementation of 
access-to-T type with user operation to provide access-to-T result. BTW, 
a type can be both access-to-T and access-to-V. Why not? But this is 
another story because smart pointers need not to be access, not visibly.

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