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 12:16:07 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: gmc444@yahoo.com (Greg C)
Newsgroups: comp.lang.ada
Subject: Re: Ada / C++ comparison paper
Date: 20 Dec 2001 12:16:06 -0800
Organization: http://groups.google.com/
Message-ID: <62340e2a.0112201216.3480a14f@posting.google.com>
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>
 <1008859296.991767@master.nyc.kbcfp.com>
NNTP-Posting-Host: 65.209.183.171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1008879367 5901 127.0.0.1 (20 Dec 2001 20:16:07
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 20 Dec 2001 20:16:07 GMT
Xref: archiver1.google.com comp.lang.ada:18165
Date: 2001-12-20T20:16:07+00:00
List-Id: <comp.lang.ada>

"Hyman Rosen" <hyrosen@mail.com> wrote in message news:<1008859296.991767@master.nyc.kbcfp.com>...
> "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.

Well, this is getting way off-topic for comp.lang.ada, but here
is an Eiffel version of what you sketched out above, compiled
and executed with the SmallEiffel compiler
(http://smalleiffel.loria.fr)

The compiler doesn't catch B referencing an A object at compile time,
but it the error can be trapped at runtime with an assertion declared
in A. Even though class B redefines "foo" the redefined version still
has to conform to A's contract, and indeed, the violation you talk
about is detected.

I think the notion that these violations can be found at compile time
is an ideal , but Eiffel compiler writers understand that this is an
ideal only and so there are facilities to detect these kinds of
problems at runtime.

Greg

------------
class A creation make
feature 
   make is do end 

   foo(in: like Current) is 
      require 
         in.conforms_to(Current)
      do  
         print("Foo of A%N")
      end 
end -- A
-----
class B
inherit A redefine foo end; 
creation make

feature 
   foo(in: B) is 
      do  
         print("foo B%N")
      end 
end -- B
--------
class TEST
creation make
feature 
   make is 
      local a, ab: A;
      do  
         create a.make;
         create {B} ab.make;
         apply(a,a);
         apply(a,ab);
         apply(ab,ab);
         apply(ab,a)  -- Assertion violation
      end 
feature 
   apply(one, two: A) is 
      do  
         one.foo(two)
      end 
end -- TEST

------------- output
Foo of A
Foo of A
foo B
Line : 7 column 15 in .\a.e.
*** Error at Run Time *** :
   Target is not valid (not the good type).
   Expected: "B", Actual: "A".