Chair of Software Engineering CAT calls (Changed Availability or Type) these slides contain advanced material and are optional.

Slides:



Advertisements
Similar presentations
Optional Static Typing Guido van Rossum (with Paul Prescod, Greg Stein, and the types-SIG)
Advertisements

Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Eiffel: Analysis, Design and Programming Bertrand Meyer (Nadia Polikarpova) Chair of Software Engineering.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Exercise Session 1: Eiffel Introduction.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Constants, once routines, and helper functions these slides contain advanced material and are optional.
Inheritance 2 Ranga Rodrigo Based on Mark Priestley's Lectures.
Languages for.NET: Eiffel Raphael Simon (ISE) Emmanuel Stapf (ISE)
Chair of Software Engineering Object-Oriented Software Construction Bertrand Meyer Lesson 21 Last update: 25 May 2004 Type issues, covariance and catcalls.
1 Advanced Material The following slides contain advanced material and are optional.
Typing Issues and LSP Amit Shabtay. March 3rd, 2004 Object Oriented Design Course 2 Typing Static typing Readability (Java vs. Pearl) Catching errors.
Chair of Software Engineering Piotr Nienaltowski, , Concurrent Object-Oriented Programming Bertrand Meyer, Piotr Nienaltowski.
1 Advanced Material The following slides contain advanced material and are optional.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 12, 12 May Advanced Topics in Object Technology Bertrand Meyer.
Principles of Object-Oriented Software Development The language Eiffel.
Java Generics. 2 The Dark Ages: Before Java 5 Java relied only on inclusion polymorphism  A polymorphism code = Using a common superclass Every class.
1 Advanced Material The following slides contain advanced material and are optional.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Covariance & anchored types 2 Covariance? Within the type system of a programming language, a typing rule or a type conversion operator is*:
Chair of Software Engineering OOSC - Lecture 21 1 Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Avoid a void Bertrand Meyer ©Bertrand Meyer, 2008.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 9: Contracts and Inheritance (based on work with.
Eiffel: Analysis, Design and Programming Bertrand Meyer Chair of Software Engineering.
Chair of Software Engineering 1 Introduction to Programming Exercise Session Week 9 M. Piccioni 17/18 November 2008.
Chair of Software Engineering ATOT - Lecture 23, 23 June Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 6: Genericity.
1 Introduction to: Design by Contract Fall 2005 OOPD John Anthony.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 10.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 7.
1 L40 Generics (2). 2 OBJECTIVES  To understand raw types and how they help achieve backwards compatibility.  To use wildcards when precise type information.
Chair of Software Engineering ATOT - Lecture 7, 23 April Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 20: Multiple inheritance.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 10.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 9: Abstraction.
Chair of Software Engineering ATOT - Lecture 22, 18 June Advanced Topics in Object Technology Bertrand Meyer.
©The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter Chapter 17 Animated Version Generics and Type Safety.
1 Genericity Parameterizing by Type. 2 Generic Class One that is parameterized by type  Works when feature semantics is common to a set of types On object.
Chair of Software Engineering Beyond Eiffel these slides contain advanced material and are optional.
10 Conversion. Let’s start with conformance Conformance determines when a type may be used in lieu of another. Conformance relies on inheritance. The.
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
Eiffel Naeem Esfahani University of Tehran "Man cannot discover new oceans unless he has the courage to lose sight of the shore." -- Andre Gide.
1 COSC3557: Object-Oriented Programming Haibin Zhu, Ph. D. Associate Professor of CS, Nipissing University.
Design by Contract in Java Concept and Comparison.
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
Contracts for Concurrency - Contracts & Inheritance Aryabrata Basu University of Georgia.
Genericity Ranga Rodrigo Based on Mark Priestley's Lectures.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 12: Subtyping Rules What’s the.
Type == Class  reference type -- store only the object’s address  simple (primitive) type -- for storing small data values Other options Wrapper classes.
Cs205: engineering software university of virginia fall 2006 David Evans Substitution Principle.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 14: Substitution Principle.
Conformance Object-Oriented Programming Spring
Ceg860 (Prasad)L17IT1 Inheritance Techniques Subcontracting Anchored Types.
CSCI-383 Object-Oriented Programming & Design Lecture 24.
1 Exceptions When the Contract is Broken. 2 Definitions A routine call succeeds if it terminates its execution in a state satisfying its contract A routine.
CSC 520 – Advanced Object Oriented Programming, Fall, 2010 Thursday, September 30 Week 5, Generics and Inheritance Techniques, Meyer Ch. 10 & 16.
CSCI 383 Object-Oriented Programming & Design Lecture 22 Martin van Bommel.
Chair of Software Engineering Void safety these slides contain advanced material and are optional.
Polymorphism in Methods
Ranga Rodrigo Based on Marc Priestley's Lectures
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Component Based Software Engineering
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Lecture 13: Subtyping Rules Killer Bear Climber
Presentation transcript:

Chair of Software Engineering CAT calls (Changed Availability or Type) these slides contain advanced material and are optional

Changed Availability or Type (CAT) Changed Availability (export status) – Lifting restrictions – Tighten restirctions Changed Type (argument or result type) – Covariant redefinition (changing to a narrower type) – Contravariant redefinition (changing to a wider type) 2

Why change availabilty or type? Greater expressiveness when modeling 3 BIRD OSTRICH fly ??? CUSTOMER BEVERAGE MINOR SOFTDRINK ALCOHOL drink: BEVERAGE serve (b: BEVERAGE) do drink := b end drink: SOFTDRINK serve (b: SOFTDRINK) do drink := b end

Changed availability Changed Availability (export status) – Lifting restrictions – Tighten restirctions 4 class A feature {X} f end class A feature {X} f end class B Inherit A export {ANY} f end end class B Inherit A export {ANY} f end end class C Inherit A export {NONE} f end end class C Inherit A export {NONE} f end end

Possible problems 5 class A feature {X} f end class B inherit A export {ANY} f end end class C inherit A export {NONE} f end end class A feature {X} f end class B inherit A export {ANY} f end end class C inherit A export {NONE} f end end class X feature make local a: A do a := create {B} a.f a := create {C} a.f end class X feature make local a: A do a := create {B} a.f a := create {C} a.f end {B}.f is available to all classes, including X {C}.f should not be available to X

Solution to availability problem When inheriting conformingly, restricting export status is not allowed anymore (Eiffel standard 2006) – EiffelStudio still allows it for backwards compatibility When inheriting non-conformingly, restricting export status is allowed 6 class C Inherit {NONE} A export {NONE} f end end class C Inherit {NONE} A export {NONE} f end end class A feature {X} f end class A feature {X} f end local a: A do a := create {C} a.f end local a: A do a := create {C} a.f end Invalid assignment. C does not conform to A Invalid assignment. C does not conform to A

Changed type: covariant 7 class A feature f (a: ANY): ANY deferred end class A feature f (a: ANY): ANY deferred end class B inherit A redefine f end feature f (a: STRING): ANY do a.to_upper create Result end class B inherit A redefine f end feature f (a: STRING): ANY do a.to_upper create Result end class C inherit A redefine f end feature f (a: ANY): STRING do a.do_nothing create Result. make_from_string (a.out) end class C inherit A redefine f end feature f (a: ANY): STRING do a.do_nothing create Result. make_from_string (a.out) end class X feature make local a: A do a := create {B} a.f (1).do_nothing a := create {C} a.f (1).do_nothing end class X feature make local a: A do a := create {B} a.f (1).do_nothing a := create {C} a.f (1).do_nothing end Covariant redefinition of argument type: Call to invalid feature. Covariant redefinition of result type: Call Ok.

Changed type: contravariant 8 class X feature make local a: A do a := create {B} a.f ("abc").append ("def") a := create {C} a.f ("abc").append ("def") end class X feature make local a: A do a := create {B} a.f ("abc").append ("def") a := create {C} a.f ("abc").append ("def") end class A feature f (a: STRING): STRING deferred end class A feature f (a: STRING): STRING deferred end class B inherit A redefine f end feature f (a: STRING): ANY do a.to_upper create Result end class B inherit A redefine f end feature f (a: STRING): ANY do a.to_upper create Result end class C inherit A redefine f end feature f (a: ANY): STRING do a.do_nothing create Result. make_from_string (a.out) end class C inherit A redefine f end feature f (a: ANY): STRING do a.do_nothing create Result. make_from_string (a.out) end Contravariant redefinition of result type: Call to invalid feature. Contravariant redefinition of argument type: Call Ok.

ANY.is_equal Routine {ANY}.is_equal has anchored argument: This is a covariant redefinition in every type You should never use is_equal directly Use the ~ -operator, which checks the dynamic type of both entities before calling is_equal 9 is_equal (other: like Current): BOOLEAN do... end is_equal (other: like Current): BOOLEAN do... end f (a, b: ANY): BOOLEAN do Result := a.is_equal (b) Result := a ~ b end f (a, b: ANY): BOOLEAN do Result := a.is_equal (b) Result := a ~ b end could be invalid at runtime always safe

Changed type: summary It is safe to: – Change result type covariantly – Change argument type contravariantly It is unsafe to – Change result type contravariantly – Change argument type covariantly Eiffel allows – Covariant change of result type (safe) – Covariant change of argument type (unsafe) 10

CAT as contracts 11 class CHILD inherit PARENT feature f (a: ANY): ANY require type_of (Caller).conforms_to ({NONE}) type_of (a).conforms_to ({C}) ensure type_of (Result).conforms_to ({A}) end class CHILD inherit PARENT feature f (a: ANY): ANY require type_of (Caller).conforms_to ({NONE}) type_of (a).conforms_to ({C}) ensure type_of (Result).conforms_to ({A}) end class PARENT feature {X} f (a: B): B end class PARENT feature {X} f (a: B): B end A A B B C C class PARENT feature f (a: ANY): ANY require type_of (Caller).conforms_to ({X}) type_of (a).conforms_to ({B}) ensure type_of (Result).conforms_to ({B}) end class PARENT feature f (a: ANY): ANY require type_of (Caller).conforms_to ({X}) type_of (a).conforms_to ({B}) ensure type_of (Result).conforms_to ({B}) end ANY X X class CHILD inherit PARENT feature {NONE} f (a: C): A end class CHILD inherit PARENT feature {NONE} f (a: C): A end NONE Stronger precondition Weaker postcondition

Generic conformance 12 class APPLICATION feature make local any_list: LIST [ANY] string_list: LIST [STRING] integer_list: LIST [INTEGER] do string_list := any_list string_list := integer_list integer_list := any_list integer_list := string_list any_list := string_list any_list := integer_list end class APPLICATION feature make local any_list: LIST [ANY] string_list: LIST [STRING] integer_list: LIST [INTEGER] do string_list := any_list string_list := integer_list integer_list := any_list integer_list := string_list any_list := string_list any_list := integer_list end      

Changed types due to generics 13 class LIST [G] feature put (a: G) do end first: G end interface class LIST [ANY] feature put (a: ANY) first: ANY end interface class LIST [STRING] feature put (a: STRING) first: STRING end class LIST [G] feature put (a: G) do end first: G end interface class LIST [ANY] feature put (a: ANY) first: ANY end interface class LIST [STRING] feature put (a: STRING) first: STRING end LIST [STRING] conforms to LIST [ANY], thus the changed type in the argument and result are like a covariant redefinition.

Problems with generics 14 class APPLICATION feature make local any_list: LIST [ANY] string_list: LIST [STRING] do create string_list.make any_list := string_list any_list.put (1) string_list.first.to_upper end class APPLICATION feature make local any_list: LIST [ANY] string_list: LIST [STRING] do create string_list.make any_list := string_list any_list.put (1) string_list.first.to_upper end Wrong element type!

Different solutions for generics Novariant conformance – No conformance between generics of different type – Used by C# Usage-site variance – Specify conformance for each generic derivation – Used by Java Definition-site variance – Specify conformance for each generic class – Implemented by CLR 15

Possible solution: Type intervals All types have an upper and lower bound Special abbreviations: Calls on any entity have to be valid for any possible type in the interval 16 c: CUSTOMER..MINOR c1: CUSTOMER c2: frozen CUSTOMER c1: CUSTOMER c2: frozen CUSTOMER c1: CUSTOMER..NONE c2: CUSTOMER.. CUSTOMER c1: CUSTOMER..NONE c2: CUSTOMER.. CUSTOMER c: CUSTOMER..MINOR c.serve (vodka) c: CUSTOMER..MINOR c.serve (vodka) Invalid, since invalid for MINOR c: CUSTOMER..CUSTOMER c.serve (vodka) c: CUSTOMER..CUSTOMER c.serve (vodka) Valid

Possible solution: usage-site variance Conformence of different generic instantiations require variant mark You can’t call features on entities using the variant mark that have a formal generic parameter type. 17 justin: MINOR bus: LIST [CUSTOMER] vbus: LIST [variant CUSTOMER] school_bus: LIST [MINOR] justin: MINOR bus: LIST [CUSTOMER] vbus: LIST [variant CUSTOMER] school_bus: LIST [MINOR] vbus := school_bus vbus.extend (justin) vbus := school_bus vbus.extend (justin) bus := school_bus bus.extend (justin) bus := school_bus bus.extend (justin) Invalid Ok Invalid Ok