Re: Smart pointers and delegation

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

On 2017-08-03 05:36, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:olrqum$1t4b$1@gioia.aioe.org...
>> 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.
> 
> As I noted at the end of my message, your proposal does not replace the "use
> case" for Implicit_Dereference. So this isn't true.
> 
>>> 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.
> 
> I think you need to concentrate on describing that problem rather than any
> particular solution to solve it. It doesn't seem like a problem that is
> really solveable in the general case. (Certainly if you want to make some
> sort of proposal; not so much if you are just making talk here.)

I have no illusions (:-)) So talk would be just fine. Especially if in 
the end the concept catches interest. Delegation is a very powerful 
mechanism which requires very little if any language tampering. It is a 
very nice alternative for generics which does not generate a whole 
second language tier unreadable and unmaintainable.

>>> 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.
> 
> In the intended use, Implicit_Dereference is always combined with a
> controlled type, which provides the actual hooks.

? These are not hooks on the operation of dereferencing.

[E.g. you cannot make a task-safe dereferencing by taking a lock at the 
beginning and releasing it at the end, i.e. a typical Ref/Unref pair]

[...]

>>> 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.
> 
> That's the problem: the Implicit_Dereference mechanism is intended for the
> rare cases where "normal primitive operations" don't work (because they
> imply copies for function results). If "normal primitive operations" work,
> you don't need (and shouldn't use) any special mechanism.

I must and I need it, because in real-life examples (e.g. #1) it is many 
thousands lines of noise code in both package declarations and bodies. 
Which is quite error-prone too.

>  From your description, you're trying to solve an altogether different
> problem. That's fine, of course, but just don't confuse that with the rather
> low-level problem that Implicit_Dereference was actually trying to solve.

Yes it is a wider problem, but one use-case is exactly same. The 
solution is different:

1. Dereference:

    type Target_Interface is interface;
    type Reference (Pointer : access Target_Interface) is null record
       with Implicit_Dereference => Pointer;

2. Delegation:

    type Target_Interface is interface;
    type Reference is new Target_Interface record
       Pointer : access Target_Interface'Class
    end record
       with Delegate => Pointer;

Delegation has no magic whatsoever. It could be done by an ASIS-aware 
preprocessor actually.

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