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=unavailable 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!newsfeed1.swip.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 08 Jun 2014 11:40:54 +0200
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: a new language, designed for safety !
References: <lmj8s6$hhp$1@speranza.aioe.org>
 <3bf7907b-2265-4314-a693-74792df531d1@googlegroups.com>
 <wccha40e9zh.fsf@shell01.TheWorld.com> <lmpcc6$ivv$1@speranza.aioe.org>
 <wccfvjj3rqf.fsf@shell01.TheWorld.com>
 <51e9fd4f-e676-4d2f-9e21-1c782d71092e@googlegroups.com>
 <5391ffa4$0$6611$9b4e6d93@newsspool4.arcor-online.net>
 <bveg7aFc4f7U1@mid.individual.net>
In-Reply-To: <bveg7aFc4f7U1@mid.individual.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <53942fa4$0$6670$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 08 Jun 2014 11:40:52 CEST
NNTP-Posting-Host: 76e34b5a.newsspool3.arcor-online.net
X-Trace: 
 DXC=?k:MeYH9WP7RadXUBHgFh3McF=Q^Z^V384Fo<]lROoR18kF<OcfhCO;B_QmXYGIhN8PCY\c7>ejV8W=G^I07B\D6WDcF87Zd5g3
X-Complaints-To: usenet-abuse@arcor.de
Xref: news.eternal-september.org comp.lang.ada:20179
Date: 2014-06-08T11:40:52+02:00
List-Id: <comp.lang.ada>

On 06/06/14 20:39, Niklas Holsti wrote:

>> with Pak;
>> procedure Comptime
>> is
>>     Obj : Pak.P2.T;
>>     X : Pak.P1.A'Class := Obj;
>> begin
>>     Pak.P3.TA'Class(X).Op;  -- run-time dispatching
>
> The error, as I understand it, is trying to convert X, which is of a
> classwide type covering Pak.P2.T, to a classwide type (Pak.P3.TA'Class)
> which does not cover Pak.P2.T. (Apologies if I'm not using the correct
> ARM terms for this.) The dispatching call is not the problem.


While the technical side of the error has now been correctly
classified, does this difference in run-time mechanics between
Ada and Objective-C make a difference on the programming side?

The programmer is making assumptions about the type of
an object. When the programming situation is characterized
by dropping pedantry of language, if I may, then his or her
assumptions will be, respectively,

- "I can view this Obj as of type TA and call Op"
     (Ada, wrong view)

- "I can send Op: to Obj of presumed type TA"
    (Objective-C, no method)

Neither the Ada compiler nor the Objective-C compiler will detect
the error. The detection of these errors at run-time is different
per language. But does this make a difference either when programming,
or when collecting the remains of a stopped program?

The only difference I can see is that Ada provides for
a formal description of something, while Objective-C
provides for a semi-formal description of the lack of
something.

When correcting the error in either language, will their be
similarities?