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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: "Norman H. Cohen" Subject: Re: OO, C++, and something much better! Date: 1997/01/27 Message-ID: <32ECD432.72EE@watson.ibm.com>#1/1 X-Deja-AN: 212712524 references: <32E774C4.534B@watson.ibm.com> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; I) Date: 1997-01-27T00:00:00+00:00 List-Id: Don Harrison wrote: > :Distinct types are > :disjoint sets of values distinguished at compile time. > > Don't agree. I think they must simply be *different* sets of values. In the > special case where the set of values is a subset of the values of another > type, you have a sub-type (in the Ada sense). > > :Subtypes of a > :type are (possibly overlapping) sets of values in the same type, > :distinguished by whether or not they obey certain constraints that can, > :in general, only be checked at run time. > > Yes ... "according to the Ada definition". > > The real issue, as far as I'm concerned, is that type safety (not surprisingly) > depends on the definition a type. A language such as Eiffel might be regarded > as type-unsafe purely because it regards sub-types as distinct types. These > types - and their attendant runtime constraint violations - are materially > no different from equivalent sub-types in Ada - which also cause runtime > constraint violations. Don, I think you are still being confused by terminology. A "subtype" in Ada has almost nothing to do with a "subtype" in Eiffel. Rather, what you are calling a subtype in Eiffel corresponds quite closely to a derived type in Ada. Just as a run-time error can occur in Eiffel converting from a type to a subtype (i.e., casting downward in the inheritance hierarchy), an exception can occur in Ada converting from a type T'Class to a type directly or indirectly derived from T. These run-time errors are analogous. Ada range checks (which check for membership in a scalar subtype) are a totally different animal. If you are saying simply that Ada is not completely type-safe because conversion from T'Class to a descendent of T may or may not fail a run-time check, depending on the tag of the object being converted, I have no argument. To accommodate the flexibility provided by polymorphic programming, Ada relaxes compile-time type checks in this one instance, replacing the compile-time check by a run-time check--but only when the programmer explicitly requests this by writing a downward type conversion. In either Eiffel or Ada, conversion downwards in a type hierarchy should be rare in a good object-oriented design. (Java is another matter. The Java language-defined container classes all contain elements of class Object, so upon extracting an object from a Dictionary, for example, you must cast it downward in the hierarchy to the class of the values contained in the Dictionary. Typically, all Dictionary values belong to a class much more specialized than Object, and the programmer knows what this class is, but Java provides no way to declare this, to let the compiler use this information to type-check insertions, and to exploit the information to avoid the run-time check inherent in downward casting.) -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen