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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,af0c6ea85f3ed92d
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.241.37 with SMTP id wf5mr17352514pbc.4.1329814086153;
        Tue, 21 Feb 2012 00:48:06 -0800 (PST)
Path: 
 wr5ni50643pbc.0!nntp.google.com!news2.google.com!goblin1!goblin2!goblin.stu.neva.ru!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 21 Feb 2012 09:47:37 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Arbitrary Sandbox
References: <bfeb9869-9323-4ad5-bdf8-af20593734ef@q8g2000pbb.googlegroups.com>
 <2aaee0a4-e820-4a75-bbaf-d9d09c366d2c@f5g2000yqm.googlegroups.com>
 <4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com>
 <jh7739$9os$1@munin.nbi.dk>
 <203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com>
 <jhh6qr$9av$1@munin.nbi.dk>
 <e10bf38c-3c48-4fa4-bb0a-e61211aee90d@f30g2000yqh.googlegroups.com>
 <193cr8xol0ysi.14p4cp2yxnb0r$.dlg@40tude.net>
 <op.v9veuwe6ule2fv@douda-yannick>
 <1jleu301thnd3$.s23priwn3ajb$.dlg@40tude.net>
 <wccobswc6ob.fsf@shell01.TheWorld.com>
 <18o3vqsl9uy2$.a3m68cg8ysro.dlg@40tude.net>
 <wccvcn1nl0x.fsf@shell01.TheWorld.com>
In-Reply-To: <wccvcn1nl0x.fsf@shell01.TheWorld.com>
Message-ID: <4f435a29$0$7608$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 21 Feb 2012 09:47:37 CET
NNTP-Posting-Host: bef1ff71.newsspool1.arcor-online.net
X-Trace: 
 DXC=b3WU5]4`oOKgj[ZPFj7ehOic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgBA<7?N^Tb48HPCY\c7>ejVH@11=^KR<EEAZJ:YYP3InjF
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-02-21T09:47:37+01:00
List-Id: <comp.lang.ada>

On 21.02.12 00:27, Robert A Duff wrote:
> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:

>>> The kind of architecture that is overly complicated
>>> and grossly inefficient.  Imagine a private type with
>>> discriminants.  The discriminant of each object is visible
>>> to clients; other components are not.  Or imagine a private
>>> extension of a (visible) record extension.  What about the
>>> fact that some portion (not all) of a child package has
>>> visibility on the private part (but not the body) of the
>>> parent package?
>>>
>>> Why do work at run time that can be done at compile time?
>>
>> Because it cannot (in presence of Unchecked_Conversion and similar stuff).
>
> If U_C etc. causes trouble, use Java.

How does using Java prevent trouble in this case?
I mean, the notion of JNI checking (if that's a close relative of
Ada's unchecked constructs) shows that Java is no better in this case,
asking programmers to be careful.

>  Or use a subset of Ada that
> doesn't allow such features.  I really can't imagine a sensible way to
> use such features and check them at run time.