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-Language: ENGLISH,ASCII
X-Google-Thread: 109fba,e0a59694a441eb7b
X-Google-Thread: 103376,e0a59694a441eb7b
X-Google-Thread: fac41,e0a59694a441eb7b
X-Google-Thread: 1108a1,e0a59694a441eb7b
X-Google-Attributes: gid109fba,gid103376,gidfac41,gid1108a1,public
Path: controlnews3.google.com!postnews1.google.com!not-for-mail
From: gedb@rushcoding.co.uk (Ged)
Newsgroups: comp.lang.c++,comp.lang.ada,comp.lang.eiffel,comp.object
Subject: Re: OOP Language for OS Development
Date: 6 May 2004 02:35:51 -0700
Organization: http://groups.google.com
Message-ID: <1a81ad90.0405060135.4c8dc47b@posting.google.com>
References: <95db0572.0404142153.431fd058@posting.google.com>
 <ytOgc.39006$zm5.17464@nntpserver.swip.net>
 <c67sgr$2e0$1@news5.svr.pol.co.uk> <4088D574.2020503@tele2.fr>
 <c6ap5j$1nh$1@newsg1.svr.pol.co.uk> <c6bfs3$ed7$1@a1-hrz.uni-duisburg.de>
 <1082738747.300309@master.nyc.kbcfp.com>
 <ba03b545.0404231503.3ddeac5a@posting.google.com>
 <3AFic.17011$eK3.5247@nwrdny01.gnilink.net>
 <1a81ad90.0405050358.b1115f6@posting.google.com>
 <oLWdnfhCGNiYQwXdRVn-jw@wideopenwest.com>
NNTP-Posting-Host: 193.129.160.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1083836152 23384 127.0.0.1 (6 May 2004 09:35:52
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 6 May 2004 09:35:52 +0000 (UTC)
Xref: controlnews3.google.com comp.lang.c++:1776 comp.lang.ada:307
 comp.lang.eiffel:85 comp.object:849
Date: 2004-05-06T02:35:51-07:00
List-Id: <comp.lang.ada>

Thomas Gagn� <tgagne@wide-open-west.com> wrote in message news:<oLWdnfhCGNiYQwXdRVn-jw@wideopenwest.com>...
> Ged wrote:
> 
> >Hyman Rosen <hyrosen@mail.com> wrote in message news:<3AFic.17011$eK3.5247@nwrdny01.gnilink.net>...
> >  
> >
> >>[...]
> >>If the template happens to work for
> >>some class that doesn't conform to T, why should it be prevented from doing
> >>so?
> >>
> >>    
> >>
> >Because in Eiffel its all about the contract.
> >
> >When the interface accepts paramaters to conform to T the objects
> >author is taking on a responsibility to ensure that the feature will
> >always accept a paramater that conforms to T.  The compiler will do
> >everything it can to help the author meet that commitment.
> >  
> >
> What' the difference between that and any other statically type-checked 
> language?  Does the compiler remember what the programmer said the type 
> was and complain if they change it?

The original question was 'If the template happens to work [...] why
should it be prevented from doing so?'

The key difference between Eiffel and other statically type-checked
languages is design by contract, explicitly distinguishing between
'correct use' and 'what happens to work.'  If the pre-conditions are
met, then the post conditions are guaranteed.

Of course, the compiler cannot enforce all of this.  However, it can
provide a lot of support.