Lecture 18 Behavioral Subtyping and Eiffel Must it

Lecture 18: Behavioral Subtyping and Eiffel Must it be assumed that because we are engineers beauty is not our concern, and that while we make our constructions robust and durable we do not also strive to make them elegant? Is it not true that the genuine conditions of strength always comply with the secret conditions of harmony? Gustav Eiffel CS 655: Programming Languages David Evans University of Virginia 29 March 2001 CS 655: Lecture 18 http: //www. cs. virginia. edu/~evans Computer Science

Menu • Behavioral Subtyping Recap and Example • Eiffel’s Type System • Method overriding in C++ 29 March 2001 CS 655: Lecture 18 2

Subtype Definition (S T) 1. Subtype methods preserve the supertype methods’ behavior: • • Signatures have contravariant arguments, covariant results Pre-conditions of T imply preconditions of S; post-conditions of S imply postconditions of T. 2. Subtypes preserve supertype properties • • Invariant of S implies invariant of T. Constraint of S implies constraint of T. 29 March 2001 CS 655: Lecture 18 3

Subtype Relation 2: Preserves supertype Properties 2. Subtypes preserve supertype properties For all states p and q such that p precedes q, for all x: S: Invariant Rule IS IT [ A (xp) / xp] Constraint Rule CS CT [A (xp) / xp, A (xq) / xq ] “covariance – subtype is stronger” 29 March 2001 CS 655: Lecture 18 4

Example • Liskov & Wing showed stack bag • Is bset bag? – bset specification on the Manifest – bag in Liskov & Wing, Figure 1 29 March 2001 CS 655: Lecture 18 5

bset = type uses BSet (set for S) for all s: bset invariant max(sp. elements) <= sp. limit, min (sp. elements) >= 0. constraint sp. limit = sq. limit insert = proc (i: int) requires i <= sp. limit i >= 0. modifies s ensures spost. limit = spre. limit spost. elements = spre. elements {i} 29 March 2001 CS 655: Lecture 18 6

contains = proc (el: int) returns (bool) ensures result = el s choose = proc () returns (int) requires spre. elements {} modifies s ensures spost. elements = spre. elements – { result } result spre. elements spost. limit = spre. limit size = proc () returns (int) ensures result = | s. elements | equal = proc (t: set) returns (bool) ensures result = (s = t) 29 March 2001 CS 655: Lecture 18 7

Subtype Definition (S T) 1. Subtype methods preserve the supertype methods’ behavior: • • Signatures have contravariant arguments, covariant results Pre-conditions of T imply preconditions of S; post-conditions of S imply postconditions of T. 2. Subtypes preserve supertype properties • • Invariant of S implies invariant of T. Constraint of S implies constraint of T. 29 March 2001 CS 655: Lecture 18 8

Subtype Condition 1: Methods Rule • Methods rule: – Pre-condition “contravariance – subtype is weaker” x: s m. T. pre [ A (xpre) / xpre ] m. S. pre Replace every xpre in m. T. pre with A (xpre). Abstraction function, A : s t. – Post-condition “covariance – subtype is stronger” m. S. post m. T. post [A (xpre) / xpre, A (xpost) / xpost] 29 March 2001 CS 655: Lecture 18 9

We need an Abstraction Function A type is: < set of objects, set of values, set of methods > bset = <Oset, BSet, { insert, contains, choose, size, equal } > bag = <Obag, BBag, { put, get, card, equal } > • We need an abstraction function that maps both to the same abstract type: A : BSet BBag BSet: < s. elems, s. limit > BBag: < s. elems, s. bound > s : BSet A (s) = < s. elems, s. limit > • Renaming: R(insert) = put, R(choose) = get, R(size) = card, R(equal) = equal 29 March 2001 CS 655: Lecture 18 10

Check method choose get 1. Preserves method behavior. • Signatures: get = proc () returns (int); choose = proc () returns (int) • Pre-condition of get pre-condition of choose x : BSet get. pre [ A(xpre) / xpre ] choose. pre bpre. elems {} [A(bpre) / bpre ] spre. elems {} s : BSet; A (s) = < s. elements, s. limit > so we can replace bpre. elems with spre. elems and the implication holds. • Post-condition of choose post-condition of get – Can prove with similar renaming 29 March 2001 CS 655: Lecture 18 11

Check method insert put • Signatures: put = proc (i: int); insert = proc (i: int) • Pre-condition of put pre-condition of insert 1. x : BSet put. pre [ A(xpre) / xpre ] insert. pre | A(spre). elems | < A(spre). bound i <= sp. limit i >= 0 • NO! The subtype method has a stronger precondition, so it is not a subtype. 29 March 2001 CS 655: Lecture 18 12

Does this make sense? • Intuition: subtype is unsafe, if there is some program written for the supertype that can tell the difference • Here’s one: put (999235); insert (999235); 29 March 2001 CS 655: Lecture 18 13

uset bag? • A: S T • A : Set BBag 8 s : Set; A (s) = < s, > • Renaming: – R(insert) = put – R(size) = card R(choose) = get R(equal) = equal • Check method choose get (same as bset) 29 March 2001 CS 655: Lecture 18 14

Check method insert put • Pre-condition of put pre-condition of insert x : BSet put. pre [ A(xpre) / xpre ] insert. pre = true • Post-condition of insert post-condition of put insert. post put. post [ A(xpre) / xpre, A(xpost) / xpost] (spost. elements = spre. elements { i }) (bpost. elems = bpre. elems { i } bpost. bound = bpre. bound) [ A(bpre) / bpre, A(bpost) / bpost] recall: A (s) = < s, infinity> so (spost. elems = spre. elems { i } infinity = infinity 29 March 2001 CS 655: Lecture 18 15

Check Invariant • Need to show: IS IT [ A(xp) / xp] true (| bp. elems | <= bp. bound) [ A(bp) / bp] true (| <s. elements, infinity>. elems | <= <s. elements, infinity>. bound true • Similar for constraint • uset is a subtype of bag! Yippee! (Except: signature of equal should take a bag!) 29 March 2001 CS 655: Lecture 18 16

Summary Questions • uset bset? , bset uset? • Does the Liskov/Wing subtype relation definition match intuition? • Is it useful? 29 March 2001 CS 655: Lecture 18 17

Eiffel and I Can’t Get Up Eiffel’s Type System 29 March 2001 CS 655: Lecture 18

Normal Procedure Type Rule f = proc (p 1: P 1, . . . , pn: Pn) returns (X) g = proc (p 1: Q 1, . . . , pn: Qn) returns (Y) Qi Pi forall i in 1. . n X Y f g Procedures are contravariant on parameters, covariant on results. 29 March 2001 CS 655: Lecture 18 19

Eiffelling How can Girl override set_roomate? Covariance: (Eiffel) set_roommate (Girl) Skier set_roommate (Boy) set_roommate (Skier) Contravariance: (Sather) set_roommate (Athlete) Novariance: (C++ (complicated), Java) Boy Girl set_roommate (Skier) Athlete 29 March 2001 CS 655: Lecture 18 20

Can’t Get Up? Athlete Skier set_roommate (Skier) Boy s: skier; g: girl; b: boy; s : = g; . . . s. set_roommate (b); Girl set_roomate (Girl) 29 March 2001 CS 655: Lecture 18 21

Meyer’s Excuse Strangely enough, some workers in the field have been advocating a contravariant policy. Here it would mean that if we go for example to class RANKED_GIRL, where the result of roommate is naturally redefined to be of type RANKED_GIRL, we may for the argument of routine share use type GIRL, or rather scaringly, SKIER of the most general kind. One type that is never permitted in this case is RANKED_GIRL! Here is what, under various mathematical excuses, some professors have been promoting. No wonder teenage pregnancies are on the rise. 29 March 2001 CS 655: Lecture 18 22

What’s wrong with Meyer’s Rule? • Disallow polymorphic catcalls: s. f (t) where some subtype of s hides f or changes covariantly type of parameters of f. • Violates useful notion of subtyping: adding a new subtype breaks existing programs! – Eiffel compiler will complain for redefinition 29 March 2001 CS 655: Lecture 18 23

What does C++ really do? • Can add covariant methods in subtype, but they overload the original method, instead of overriding it! • Does this make sense? 29 March 2001 CS 655: Lecture 18 24

class skier { public: virtual void set_roommate (class skier *s) { fprintf (stderr, "skier roomate!"); } }; class girl : public skier { void set_roommate (class girl *g) { fprintf (stderr, "girl roomate!"); } }; class boy : public skier { void set_roommate (class boy *b) { fprintf (stderr, "boy roomate!"); } }; int main (void) { girl *g = new girl (); boy *b = new boy (); skier *s; s = g; s->set_roommate (b); g->set_roommate (b); } 29 March 2001 CS 655: Lecture 18 25

Result • Both g++ and MSVC++ produce compiletime errors for g->set_roommate (b) skiers. C: 27: no matching function for call to `girl: : set_roommate (boy *&)' skiers. C: 9: candidates are: void girl: : set_roommate(girl *) • After removing this line, compiles okay, produces: “skier roomate!” (calls the superclass method) • If girl: : set_roommate (girl *) overloads, but doesn’t override skier: : set_roommate why does this happen? 29 March 2001 CS 655: Lecture 18 26

Some C++ Facts • 1996 Draft Standard is 680 pages long – 50 x more complex than Algol 60! Is this progress? • Current open issues list of Core Language Issues contains 223 issues – Compare to Knuth’s 9 ambiguities in Algol 60 • Current open issues list for standard library (Revision 12) is 59 pages • Good luck! 29 March 2001 CS 655: Lecture 18 27

Date: Fri, 03 Mar 2000 18: 09: 53 -0500 From: Avneesh Saxena <avneesh@cs. virginia. edu> To: bs@research. att. com Subject: C++: overriding problems! Sir, I am Avneesh, a graduate student in the CS Dept, Univ of Virginia. I am currently taking a course on Programming languages in which we are doing a detailed study of subclassing mechanisms in computer languages. I have learned C++ from your book "The C++ Pgm'ing Language" which is written in a very clear and concise manner. Especially, the concepts are made clear and ambiguties about language features have been discussed and resolved in an appreciable manner. However, I have run in a problem while trying to figure out what this code would do: 29 March 2001 CS 655: Lecture 18 28

. . . (example same as ours but less of a social statement) I have tried to run this code both through GCC v 2. 8. 1 and MS-VC++, which give the same results. It appears that while we would accept other() to be accessible through the derived classes, the compiler doesn't find it. The second (more serious)problem is when other(b. Ptr) is called, we expect it to execute the function which has been defined in class B as it overrides the function defines in class A as the type of the actual argument matches this more closely; however, it executes the base classes function (circumvents polymorphism!). I tried to check if this behavior was consistent with the language definition but I failed to find anything which would clarify things. So, I am left wondering whether this is a case of the compiler not understanding the language and doing something wrong or is it what the language desires? I hope you will be able to clarify things for me, Thanks, Avs 29 March 2001 CS 655: Lecture 18 29

Subject: Re: C++: overriding problems! Date: Sat, 4 Mar 2000 20: 19: 34 -0500 (EST) From: Bjarne Stroustrup <bs@research. att. com> To: avneesh@cs. virginia. edu >. . . (copy of Avneesh’s message elided) Your problem is that you think that the two other() function overloads. They don’t functions in different scope do not overload, so when you look at scope C: : other(). If you want overloading you'll have to explicitly do so in C. One simple way of doing so is to say: using B: : other; in C, but that's a relatively new feature > I have tried to run this code both through GCC v 2. 8. 1 and MS-VC++, which give the same > results. It appear that while we would accept other() to be > accessible through the derived classes, the compiler doesn't find it. I think you mean "expect", but you expect wrongly. >. . . So, I am left wondering whether this is a case of the compiler not understanding the language and doing something wrong or is it what the language desires? The compilers are wrong I suggest a re-read of the sections about deriving classes in your textbook. 29 March 2001 CS 655: Lecture 18 30 >

Emailing Experts • All of you should (soon if not already) have email exchanges with experts relevant to your projects • One good email can save you reading thousands of pages! • Good to build your research contacts 29 March 2001 CS 655: Lecture 18 31

Date: Fri, 03 Mar 2000 18: 09: 53 -0500 From: Avneesh Saxena <avneesh@cs. virginia. edu> To: bs@research. att. com Subject: C++: overriding problems! Be polite Sir, Introduce Yourself (be brief) Flattery. I am is Avneesh, a graduate student in the CS Dept, Do. Univ yourofhomework always a good Virginia. I am currently taking a course on Programming first languages which we are doing a detailed study of subclassing idea! (okay toinlie mechanisms in computer languages. I have learned C++ from a little if your book "The C++ Pgm'ing Language" which is written in a very necessary) clear and concise manner. Especially, the concepts are made clear and ambiguties about language features have been discussed and resolved in an appreciable manner. However, I have run in a problem whileask trying to figure outspecific what Concisely a clear and this code would do: question. 29 March 2001 CS 655: Lecture 18 32

Charge • Be ready for elevator speeches next week: – Convince the class your project is interesting and worthwhile in 90 seconds • Next time: pragmatic aspects of OO languages - comparison of Sather, Eiffel, Java and C++ 29 March 2001 CS 655: Lecture 18 33