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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: donh@syd.csa.com.au (Don Harrison) Subject: "(Sub)type" -safety Date: 1997/01/29 Message-ID: #1/1 X-Deja-AN: 212925892 sender: news@syd.csa.com.au x-nntp-posting-host: dev50 references: <32ECD432.72EE@watson.ibm.com> organization: CSC Australia, Sydney reply-to: donh@syd.csa.com.au newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1997-01-29T00:00:00+00:00 List-Id: Thread renamed and cross-posting restricted to cle and cla. Norman H. Cohen writes: :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. Not "confused by", but thanks for the suggestion :) :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. Yes, it's true that the closest analogue of Eiffel "subtypes" in Ada is probably derived types. Also, I acknowledge that the analogue of Ada subtypes is not Eiffel "subtypes". A better analogue might be preconditions on routines. These effectively create (in my mind, if no-one else's :)) an anonymous "(sub)type". eg. do_something (a: INTEGER) is require in_range: a >= 1 and a <= 10 ... This may be what Matthew had in mind. :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), Eiffel's actually a bit different here. This occurs implicitly in two types of reattachment: 1) Reserse assignment attempt (which doesn't cause a runtime error), and 2) Operation parameter substitution (which may). :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. Fair enough. :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. I wasn't but accept that it's true. :In either Eiffel or Ada, conversion downwards in a type hierarchy should :be rare in a good object-oriented design. True. :(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.) Hopefully, we've reached some agreement and you can get back to aguing with the Smalltalkers. :) Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au