Re: Private extension of a synchronized interface

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

On 2019-02-17 16:36, Jere wrote:
> On Sunday, February 17, 2019 at 9:52:42 AM UTC-5, Dmitry A. Kazakov wrote:
>> 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.
>>
> The compiler cannot always tell depending on how and where you call buried
> protected operations.

But it is the reverse. You do not promise not to implement it as a 
protected operation, you promise to do it protected straight away!

> I always prefer compile time catching over run time catching.

It is a weaker precondition, nothing to catch at all.

>>> 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.
> 
> Protected procedures/functions/entries are particularly heavy operations.
> I don't know if you generally work in low level embedded environments,
> but being able know and plan for that can be very critical.  It can
> change how you approach your design.  When you work in systems where
> your system clock is 1-4MHz, timing of operations does start to matter.

Again, you are talking about the reverse:

    type T is not synchronized but still limited interface; -- (:-))

and there is no actual use for this either.

As a general note, "heaviness" is non-functional, ergo cannot be in a 
contract.

>>> 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...
>>
> I'm just curious if or why the process was stopped half way instead of
> abandoned or completed (again that is assuming I didn't use the wrong
> syntax, in which case it's simply that I'm structuring the syntax wrong).

I think nobody had an idea how to make protected objects/tasks 
extensible. How would you override entries of a task buried in accept 
statements of the parent's task body?

Javaesque interface with a one-set inheritance seemed simple to do. It 
is no half way, you basically not even left the house.

> I don't really need to marry them with tagged types.  I do appreciate
> the ability to dispatch over a group of related but different tasks
> much more easily and the interfaces give that.  The way that Ada chose
> to implement interfaces is one of many ways (not all of which would
> have required tagged types).

Yet another half measure. If only tagged types may have classes then 
tasks must be kind of tagged.

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