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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,198c6302c4a0b0d7
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-12-20 06:41:43 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!newsswitch.lcs.mit.edu!newsfeed.mathworks.com!news.mathworks.com!uunet!nyc.uu.net!ash.uu.net!spool0900.news.uu.net!reader0902.news.uu.net!not-for-mail
From: "Hyman Rosen" <hyrosen@mail.com>
Newsgroups: comp.lang.ada
References: <3c1dc786@pull.gecm.com> <1008601517.470745@edh3>
 <1008626816.690418@master.nyc.kbcfp.com> <9vls3v$en1$1@nh.pace.co.uk>
 <3C1E941C.5010402@mediaone.net>
 <P2ET7.25032$4e3.3277598@news6-win.server.ntlworld.com>
 <1008697855.857274@master.nyc.kbcfp.com>
 <62340e2a.0112190810.16f029ff@posting.google.com>
Subject: Re: Ada / C++ comparison paper
Date: Thu, 20 Dec 2001 09:41:36 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Organization: KBC Financial Products
Message-ID: <1008859296.991767@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@fixedcost.nyc.kbcfp.com
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1008859292 reader2.ash.ops.us.uu.net 5380 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:18146
Date: 2001-12-20T09:41:36-05:00
List-Id: <comp.lang.ada>


"Greg C" <gmc444@yahoo.com> wrote in message
news:62340e2a.0112190810.16f029ff@posting.google.com...
> Actually, this is not true. In Eiffel the parent's methods can declare
> parameter types such that child classes can be substituted.

"Can" but not "must". In C++ terms, Eiffel allows this:

struct a { virtual void f(const a &p_a) const; };
struct b : a { virtual void f(const b &p_b) const; };

with b::f considered the overrider of a::f. Now, suppose
I have this function:

void apply(const a &a1, const a &a2) { a1.f(a2); }

Even though this compiles without any problem, I have
no assurance that it will not fail at runtime, because it's
possible for a1 to refer to a "b" object while a2 refers
to an "a" object. Eiffel advocates hope for whole-program
analysis to save them from this by trying to track whether
such a case actually arises. Feh.