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 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: "Matthew Heaney" Subject: Re: OO puzzle Date: 2000/01/03 Message-ID: <38714168_1@news1.prserv.net>#1/1 X-Deja-AN: 567963897 Content-transfer-encoding: 7bit References: <386102F6.56CEFA22@averstar.com> <83sq9g$5ml$1@nnrp1.deja.com> <386C07D7.A24A36F5@shadow.net> <386CFDEB.946C3336@shadow.net> Content-Type: text/plain; charset="US-ASCII" X-Complaints-To: abuse@prserv.net X-Trace: 4 Jan 2000 00:40:08 GMT, 32.101.8.103 Organization: Global Network Services - Remote Access Mail & News Services Mime-version: 1.0 Newsgroups: comp.lang.ada Date: 2000-01-03T00:00:00+00:00 List-Id: In article <386CFDEB.946C3336@shadow.net> , Jeffrey L Straszheim wrote: > Of course it's not the same: no two different things are ever the > same. To use Peter Wegner's terminology, it's the difference between "type semantics" and "template semantics." What "type semantics" means is that for a (scalar) type, you constrain the range of possible values. What "template semantics" means is that for a (tagged type) class, you constrain the set of possible types, and therefore constrain the set of operations possible. So you are comparing apples and oranges. If you're going to grok the Ada way of doing things, you have to think in terms of 1) scalar types with their constrained ranges 2) array types with their index constraints 3) discriminated records with their discriminant constraints and 4) tagged types and class-wide programming > The point is Ada allows me to do this: > > In some package specification: > > function Some_Opaque_Library_Function (Param: Integer) return Integer; > > In my code: > > The_Largest_Fred : constant := 135; > subtype Fred is range 0 .. The_Largest_Fred; > > A_Variable : Fred := 0; > Another_Varialbe : Fred; > > begin > > Another_Variable := Some_Opaque_Library_Function (A_Variable); > > ... > > Now, nothing guarantees that the constraint for subtype Fred won't > be violated here, causing a runtime fault. Of course, because you-the-client made an unjustified assumption about the return value of the function, by assuming a smaller range than was specified in the function profile. If there's a run-time error, then it's your fault for assuming a stronger postcondition than was guaranteed by the function specification. > (BTW, this is the sort > of place where DBC really helps, but I won't belabor that point.) Then use DBC. Declare your library function as returning subtype with a smaller range: subtype Fred is Integer range 0 .. 135; function Some_Opaque_Lib_Func (Param : Integer) return Fred; ... Variable : constant Fred := Some_Opaque_Lib_Func (P); Now you really do have a guarantee that no run-time fault will occur (assuming of course the function is error-free, and satisfies its postcondition). > Now, one can debate whether this is a (potential) type error. If > so, the debate becomes a semantic one and a waste of time, but > let me just say that by some definitions of type, this is indeed > considered a type error. Again, I'd prefer not to belabor the point. The only "definition of type" that you should care about on CLA is the Ada definition. In Ada, there is no type error in your example! A "type error" --as defined by Ada-- would have been caught at compile time. For example: type Barney is new Integer; B : constant Barney := Some_Opaque_Lib_Func (P); This assignment is illegal, and will be caught at compile time, because Barney is a different type from Integer. Your original example had a "constraint error," because you violated the range constraint of the object (which had subtype Fred). It is not a type error.