SLIDE 1
Chair of Softw are Engineering
2
The world is covariant: is it safe? Bertrand Meyer & Emmanuel - - PowerPoint PPT Presentation
The world is covariant: is it safe? Bertrand Meyer & Emmanuel - - PowerPoint PPT Presentation
The world is covariant: is it safe? Bertrand Meyer & Emmanuel Stapf Chair of Softw are Engineering Collaborations & acknowledgements Emmanuel Stapf (Eiffel Software, California) Martin Seiler, Julian Tschannen (Eiffel Software + ETH)
SLIDE 2
SLIDE 3
3
The need for covariance
CUSTOMER MINOR BEVERAGE SOFT_ DRINK ALCOHOL drink : BEVERAGE serve (b : BEVERAGE ) do drink := b ensure drink = b end drink : SOFT_DRINK serve (b : SOFT_DRINK ) do drink := b end Client Inherit
SLIDE 4
4
Defeating covariance (1)
CUSTOMER MINOR BEVERAGE SOFT_ DRINK ALCOHOL
Vodka : ALCOHOL c : CUSTOMER Shiloh : MINOR
c.serve (Vodka) c := Shiloh c.serve (b ) b := Vodka
b : BEVERAGE
drink : BEVERAGE serve (b : BEVERAGE ) do drink := b end drink : SOFT_DRINK serve (b : SOFT_DRINK ) do drink := b end
c.serve (Vodka) c := Shiloh
Client Inherit Client Inherit
SLIDE 5
5
Defeating covariance (2)
CUSTOMER MINOR BEVERAGE SOFT_ DRINK ALCOHOL
bus.item.serve (Vodka) bus : LIST [CUSTOMER]
school_bus : LIST [MINOR] Vodka : ALCOHOL c : CUSTOMER Shiloh : MINOR
bus := school_bus Generic
conformance
drink : BEVERAGE serve (b : BEVERAGE ) do drink := b end drink : SOFT_DRINK serve (b : SOFT_DRINK ) do drink := b end
SLIDE 6
6
Terminology
Catcall: incorrect application of a feature to an object as a result of
Incorrect argument type Information hiding violation
(CAT: Changed Availability
- r Type)
BIRD OSTRICH
fly ??
SLIDE 7
7
Mitigating mechanism 1: non-conforming inheritance class C inherit {NONE } B feature ... end No polymorphism permitted: b1 := c1
- - Invalid
B C
b1 : B c1 : C
SLIDE 8
8
Mitigating mechanism 2: anchored types
class CUSTOMER feature drink : BEVERAGE serve (b : BEVERAGE ) do drink := b end end class MINOR inherit CUSTOMER redefine drink, serve end feature drink : SOFT_DRINK serve (b : SOFT_DRINK ) do drink := b end end class CUSTOMER feature drink : BEVERAGE serve ( ) do drink := b end end class MINOR inherit CUSTOMER feature drink : SOFT_DRINK end
In practice: anchored types
b : like drink redefine drink end
SLIDE 9
9
Anchoring to Current
Also possible, in a class C : x : like Current In any descendant D of C (including C itself), x has type D
SLIDE 10
10
Mitigating mechanism 3: flat type checking
An assignment x := y may be valid in a routine r of a class B but not necessarily in a descendant C which only redefines x (covariantly) The Eiffel type system now specifies that every class must be independently valid “Flat type checking”
B C
r
do x := y end
x : T y : T x : U
T U
SLIDE 11
11
A typical example (EiffelBase library)
(LINKABLE) class LINKABLE [G ] feature item : G right : LINKABLE [G ] put_right ( x : like right ) do right := x end end (LINKED_LIST) (BI_LINKABLE) (TWO_WAY_LIST) class BI_LINKABLE [G ] inherit LINKABLE [G ] redefine right end feature right : BI_LINKABLE [G ] left : like right put_left (x : like right) do left := x end end
SLIDE 12
12
The practical picture
*New and redeclared features only. Rounded. Product Lines
(thousands)
65 660….. 1300….. 1900….. 99 1600 Features *
(thousands)
Covariant argument Covariant result EiffelBase 5.5 1.1% 1.3% EiffelStudio+
Libraries Client code All
51 38 89 0.7% 0.9% 0.7% 1.2% 3.1% 2.0% EiffelVision common API 6.7 0.7% 3.9% Financial system 122 1% 1.4%
Measures courtesy of Yi Wei (ETH) +Windows version
SLIDE 13
13
Explicit vs implicit covariance
Product Features with covariant args Explicit covariance like Current like x EiffelBase 59 39% 8% 52% EiffelStudio 697 53% 8% 39% Financial system 1173 59% 2% 39%
SLIDE 14
14
Type intervals
CUSTOMER MINOR drink : BEVERAGE serve (b : BEVERAGE ) do drink := b end drink : SOFT_DRINK serve (b : SOFT_DRINK ) do drink := b end
Vodka : ALCOHOL
c.serve (Vodka) c := Shiloh
c : CUSTOMER..MINOR Shiloh : MINOR
- - Now invalid
SLIDE 15
15
Type intervals c.serve (Vodka) c := Shiloh
c : CUSTOMER..MINOR
- - Now invalid
Rule: a call x.f (a), with x : T..U, must be valid when x is given any type in T..U Abbreviations: x : T means x : T..NONE LIST [T ] means LIST [T..T ] x : CUSTOMER..CUSTOMER
x.serve (Vodka) x := Shiloh
- - Now invalid
SLIDE 16
16
A simplified version c.serve (Vodka) c := Shiloh
c : CUSTOMER x: frozen CUSTOMER OK Rule: a call x.f (a), with x: T not frozen, must be valid when x is given any descendant type of T
x.serve (Vodka) x := Shiloh
Invalid OK Invalid
SLIDE 17
17
Genericity rule vbus.extend (Shiloh) vbus := school_bus
bus : LIST [CUSTOMER ] vbus : LIST [variant CUSTOMER ] school_bus : LIST [MINOR] OK Rule:
An assignment with a different actual generic
parameter requires the “variant” mark.
The variant mark precludes the use of a routine with an
argument of a formal generic parameter type Invalid OK Invalid
bus.extend (Shiloh) bus := school_bus
SLIDE 18
18
Anchored (“like”) declarations
New results:
“Flat type checking” guarantees that like Current
declarations are safe
b: like a , with a of type T, may be considered an
abbreviation not for b: T as now, but for Then only explicit (non-anchored) covariance remains! b : like a b : frozen T
SLIDE 19
19
Note
The mechanism permits export restrictions in descendants, if desired.
BIRD OSTRICH
fly ??
SLIDE 20
20
Proof framework
“Direct semantics” of Eiffel: the language is (re)-defined as a mathematical theory Routines are functions with the following signatures (George Bush principle):
Object → Value* → State → Value (query) Object → Value* → State → State
(command) Each class is associated with two sets of objects:
Direct instances Instances (includes direct instances of descendants)
A polymorphic variable may denote any instance, a non- polymorphic one only a direct instance Prove that with the rules given all applications of partial functions are within the corresponding domain
| | | |