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 13:59:13 +0200
Organization: cbb software GmbH
Message-ID: <8iym21y3cv14.1vuethuo3ua53$.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>
 <1spiuuuxfwqq4$.46v46qs98684.dlg@40tude.net>
 <521de20d$0$9507$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:17015
Date: 2013-08-28T13:59:13+02:00
List-Id: <comp.lang.ada>

On Wed, 28 Aug 2013 13:42:16 +0200, G.B. wrote:

> On 28.08.13 11:42, Dmitry A. Kazakov wrote:
>> The point Maciej does is valid and it is the issue which prevents tasks
>> from having entries proper methods supporting inheritance and overriding.
> 
> If that was the point, there still there is a huge difference
> between "normal" types with overriding and all on the one hand
> and task types on the other, namely that
> 
>   task types specify possible orders of method execution   (*)

As well as other type could do in order to maintain the object's invariant. 

BTW, this, no doubt, flawed idea is actively promoted by Ada 2012 idea of
preconditions <=> operations that are not applicable in *any* context where
arguments are valid.

As with plain types, one can argue that imposing certain order (as a
precondition) is merely bad design to be avoided when possible.

The corresponding patters for safer abstractions are sessions, transactions
etc, all in the end intended to weaken the preconditions.

> I suggest that saying "refactoring" is a far cry from being
> a satisfactory solution of (*) from the language point of view.

Refactoring *is* a solution, but the problem is that there is no good means
to refactor it easily, safely etc.

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