From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Ada advocacy
Date: Wed, 28 Aug 2013 11:42:53 +0200
Organization: cbb software GmbH
Message-ID: <1spiuuuxfwqq4$.46v46qs98684.dlg@40tude.net>
References: 
 <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7>
 <2012032020582259520-rblove@airmailnet> <jkc59a$hs5$2@speranza.aioe.org>
 <12ee9bc5-3bdf-4ac0-b805-5f10b3859ff4@googlegroups.com>
 <vhcvr8d4kq6ribdqeeb0b857ei5aa5luiv@4ax.com>
 <6c58fae4-6c34-4d7a-ab71-e857e55897c0@x6g2000vbj.googlegroups.com>
 <wccvc5b49yc.fsf@shell01.TheWorld.com> <op.w2g9br0kule2fv@cardamome>
 <246849b7-7a53-48a2-8f64-ff6dfb2086ce@googlegroups.com>
 <521dbbbb$0$9520$9b4e6d93@newsspool1.arcor-online.net>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: IenaDxMXK2hi7fvYcb+MlQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:17008
Date: 2013-08-28T11:42:53+02:00
List-Id: <comp.lang.ada>

On Wed, 28 Aug 2013 10:58:44 +0200, Georg Bauhaus wrote:

> On 28.08.13 09:45, Maciej Sobczak wrote:
>>> Why did you said "no big loss" about the rendez-vous? What's your known
>>> issues with rendez-vous? I never used concurrency a lot until now, so
>>> that's really a question, because I may  (or may not, I still don't know)
>>> have to use it.
>>
>>  The biggest issue with rendez-vous is that it is (the server-side part of
>>  it) coupled by the rules of grammar to the top level of task body. That
>>  is, all your "accept" statements must be syntactically in the task body
>>  that declared appropriate entries.
>> It looks OK in the book examples, but since it makes code refactoring impossible,
> 
> Having the accept statements in one place surely means
> you'll find the server side's tasking interface and its
> control structure (when acting), in one place.

The point Maciej does is valid and it is the issue which prevents tasks
from having entries proper methods supporting inheritance and overriding.

BUT, protected objects have problems with inheritance on their own as well
as problems with all other means of restructuring, refactoring, reuse etc. 

It is unfair to blame tasks for something protected objects do not solve
either.

It is good that Ada has both tasks and protected objects. So far nobody
came with anything better, IMO.

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