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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c5ca2cbae60e9fee X-Google-Attributes: gid103376,public From: Ehud Lamm Subject: Re: OO puzzle Date: 1999/12/23 Message-ID: <83t2vt$arh$1@nnrp1.deja.com>#1/1 X-Deja-AN: 564111495 References: <386102F6.56CEFA22@averstar.com> <83sq9g$5ml$1@nnrp1.deja.com> <83t14p$9ps$1@nnrp1.deja.com> X-Http-Proxy: 1.0 o-proxy.cc.huji.ac.il:8080 (Squid/2.2.STABLE4), 1.0 x33.deja.com:80 (Squid/1.1.22) for client 132.64.12.11, 132.64.1.34 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Thu Dec 23 12:02:29 1999 GMT X-MyDeja-Info: XMYDJUIDehudlamm Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Date: 1999-12-23T00:00:00+00:00 List-Id: In article <83t14p$9ps$1@nnrp1.deja.com>, Robert Dewar wrote: > In article <83sq9g$5ml$1@nnrp1.deja.com>, > Ehud Lamm wrote: > > I assume the importance of catching errors before runtime is > > evident. Now can we do it nicely in this case? > > Evident, but not quite so neatly trivial. Run-time errors are > of two kinds: > > 1. Statements that will always cause an error if executed. Such > errors are bound to get caught by simple coverage testing. > > 2. Statements where the error is data dependent and there is no > simple guarantee. > This is true, of course. Indeed one of the basic elements of OOP is the late binding, which allows you things like polymorphic datastructures. The price you pay is of course that some things are only checkable in runtime. So far so good. But if we delve into this, following your post, we get to less firm ground. Suupose I have a routine that receives a class wide type. Inside I expicitly convert and treat it as some specific type. If I pass an actual paramter that is class-wide (access object'class) than, obviously, the valdity of the conversion can only be checked at run time. However if I pass a specific, and incompatible type - we can imagine a compiler flagging the conversion as raising an exception. whether we design a language to do this checking, and disallow such calls is, naturally, a deisgn choice. But as opposed to the first example - this checking seems possible to do (at least in limited cases like this). The issue we discussed was an example of paramter delcartions in Eiffel, that if checked before runtime, provide more checking than is achied by some Ada examples that ostensibly defer the check to runtime. Your classifciation is correct, but in itself doesn't provide the prescriptive answer of how to design a language in such a way as to ensure as much can be done during compile time, as possible without hurting expressablity to much. This question is naturally not a question that can be answered shortly and with a defnitive answer. Hence we see some differences even among mostly similiar languages. The "system validty" issue in Eiffel, is such an issue, and comments about it are welcome. The first question, though, is if it can be checked before runtime. Tucker's response seems to imply that the answer is no. [but also brings in the question of link time checks] -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm Check it out and subscribe to the E-List Sent via Deja.com http://www.deja.com/ Before you buy.