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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,73f81e5f5d6ee80f
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 12 Dec 2008 11:50:43 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: MI is sloppy
References: <d0goewygto13.10nsyzpabm3vn.dlg@40tude.net>
 <ghpnj4$hce$1@munin.nbi.dk> <1g29uf1ygl1wc$.1x184o2bk9m0k$.dlg@40tude.net>
 <ghs1ki$vaf$1@munin.nbi.dk> <1hjx0k7xmfw4n$.14q7chpo1r1ma$.dlg@40tude.net>
In-Reply-To: <1hjx0k7xmfw4n$.14q7chpo1r1ma$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <49424203$0$31868$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 12 Dec 2008 11:50:43 CET
NNTP-Posting-Host: 963d2bd5.newsspool3.arcor-online.net
X-Trace: 
 DXC=l0kQNoK9SMhPKPPVf;4hUjMcF=Q^Z^V3h4Fo<]lROoRa^YC2XCjHcbicI\\N04\CIf;9OJDO8_SKfNSZ1n^B98ijhJbn_CA@h_d
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:3944
Date: 2008-12-12T11:50:43+01:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov schrieb:
> On Thu, 11 Dec 2008 15:44:30 -0600, Randy Brukardt wrote:

>>> Whatever way you go, incrementally adding operations or else incrementally
>>> removing them.
>> No, that's not what I meant. I meant something like:
>>
>> type File is ...
>> subtype Inout_File is ...
>> subtype In_File is ...
>> subtype Out_File is ...
>> procedure Get (A_File : in out File; Item : out Data)
>> with precondition A_File not in In_File;
>> procedure Put (A_File : in out File; Item : Data)
>> with precondition A_File not in Out_File;
> 
> To me it is exactly same. The precondition not to be in a subtype is
> equivalent to disallowing the operations specific to that subtype. Unless
> precondition is treated as a constraint check with Constraint_Error
> propagated. In the latter case Get is merely an overriding by the body
> 
> begin
>    raise Constraint_Error;
> end;
> 
> Not very exciting to me.

If you have an ambitious compiler, it might reach out,
at compile time, for objects whose behavior is then known
to be constrained by membership in a then known specific
subtype.