Re: Private extension of a synchronized interface

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

On 2019-02-17 14:46, Jere wrote:
> On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote:
>>
>> But synchronized interfaces are totally bogus from the software design
>> POV. It is a pure implementation aspect exposed. Why do you care?
>> Aggregate a protected object and delegate primitive operations to it.
>>
> 
> That's what I am doing as my own solution.  I was intrigued with the code
> above as an alternate solution because it could potentially give a
> compile time indication that a procedure was a protected operation (as
> opposed to me relying on simply providing that via comments).

Given to who? The compiler knows already, the user should not care. It 
is an implementation aspect which simply does not belong here.

What could make sense is an entry interface, a primitive operation which 
could be queued/requeued to, used in timed entry call etc.

> A delegate non protected procedure has to rely on the comment.

There is no contract that could require it protected. It is a property 
of the object/task and no property of an operation. You could not do 
anything with a task or protected object that would not resolve into a 
protected action anyway.

[...]

> However, I honestly
> wanted to know why Ada allowed one to setup the private extension but not
> allow you to actually provide the functions (or if this was a GNAT issue or
> if I was just not using the right syntax).  So the reason I care was a
> thirst for knowledge of how things work.

Ada 2005 stuff, most of it makes little sense to me. It was some 
halfhearted attempt to unite tagged types with tasks and protected 
objects with no desire to actually do that...

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