Re: Smart pointers and delegation

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

On 2017-08-02 01:06, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:olplb6$jq0$1@gioia.aioe.org...
>> I would like to discuss delegation proposal as a replacement for crude,
>> inside out Implicit_Dereference aspect.
> 
> There never are "replacements", as existing Ada code has to work.

It is not replacement in that sense. Replacement here applies to the 
"use case", i.e. creating subtypes. Implicit dereferencing effectively 
makes pointer a "subtype" of the target type.

> And as usual, you didn't explain the problem that you're trying to solve.

The problem is subtyping and automated creation of wrappers to implement 
"trivial" operations. The method is delegation. Examples are presented.

> Implicit_Dereference was designed so a programmer can get control just
> before and just after the use of a dereference.

Certainly not. There is no prologue or epilogue hooks, just one ugly 
access type exposed. Should have been any function or expression 
instead. But it is irrelevant because there is a lot of unwanted and 
damaging stuff that comes with implicit dereferencing making it unusable 
for the use cases in question. Like exposing the target type, which is 
no-no for handle/proxy types. Like making reference objects indefinite etc.

> Implicit_Dereference very much matches the Ada model of "hooks" into
> language-defined operations (much like Adjust and Finalize allow
> user-defined operations to be associated with an assignment, rather than
> replacing it).

? Not even close. Adjust and Finalize are primitive operations, which 
was a horrific design choice, but nevertheless. Implicit dereference is 
not an operation, not even a body.

> The main intended use of this feature was to manage the lifetime of accessed
> entities, such as a persistent store, without requiring copies of the
> contained data (which might be large).

Copies are very essential in many cases, e.g. an external reference to a 
database table row etc. It is up to the programmer to define the semantics.

> Your proposal doesn't meet this particular need, because there is no way to
> tell when the program is finished with a function result.

I don't understand what you mean. The proposal considers exclusively how 
to generate bodies of normal primitive operations. All current rules 
apply to them, no any new rules needed.

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