Re: Smart pointers and delegation

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:omjjlr$1ia7$1@gioia.aioe.org...
> On 2017-08-11 02:17, Randy Brukardt wrote:
...
>>> 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.

That's good, because a "plain access type" is dangerous (it has a global 
lifetime if defined in an ADT). Thus it very easily becomes dangling. If all 
you want is something for dereferences, you have to use an anonymous access 
discriminant and a call-back when done, which is the normal usage pattern of 
Implicit_Dereference (of course, you can do that without using 
Implicit_Dereference if you don't mind the extra text as in the above 
assignment).

> So usually it is a setter defined on the handle:
>
>    A (I).Set_C (Y);

That's better, but of course requires a setter for every component. Which 
necessarily merges the container and the element.

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

"Simply"? Not much of anything is "simply" in language terms. 
Implicit_Dereference is relatively simple in language terms because it is 
mainly defined in terms of a text equivalence (thus, few rules have to be 
repeated). I doubt anyone would argue that it is simple in usage terms; the 
theory was that few would care about the details of setting it up, since the 
vast majority would just use it in a container. That's very much like the 
theory behind generics. (And yes, I doubt you would agree with that theory 
in either case.)

No one suggested an idea like the one you gave here, so it certainly was not 
considered. But typically, ambiguity in a type declaration causes problems 
elsewhere. Types are the one thing in Ada that really provide an anchor: 
they can't be overloaded, they always have a single meaning (at a particular 
point in the text, it could change from visibility but nothing else), and so 
on. Changing that might be problematical. But someone would have to do a 
full analysis to be sure, and it is too late for that now.

                             Randy.