object-oriented software construction bertrand meyer lesson...

Chair of SoftwareEngineering

Object-Oriented Software ConstructionBertrand Meyer

Lesson 21

Last update: 25 May 2004

Type issues, covariance and catcalls

Programming in the Large, 20042 Chair of SoftwareEngineering

What’s special about this lecture

Mix of:

Fundamental concepts Unsolved issues Recent proposal


Flexibility vs. safety

Expressive power (no “bondage and discipline” language)

Protection against crashes and attacks


Typing approaches

Pascal

x := yOnly if types of x and y are identical!

Smalltalk x.f always permitted, not static type check! At execution time: “Message not understood”


Like Pascal in basic forms

But polymorphism allows more flexible assignment rule:

x := y permitted if type of y “conforms to”type of x

Typed O-O languages


Basic type rules in typed O-O languages

Eiffel, Java, .NET...

In every assignment x := y (or argument passing), type ofy conforms to type of x.

In every feature call x.f(…)(qualified), f is an exportedfeature of the class of x.

C++: “A little bit typed”(Casts)


Terminology

Typed vs untyped languages

More accurate:

Statically typed, vs Dynamically typed


Typing is always pessimistic

Invalid in Pascal:

var n: INTEGER

n := 0.0

if 0 > 1 thenbegin

n := 0.0end


The basic goal

A programming language is statically typed if itsdefinition includes a set of type rules, guaranteeing thatno execution of a valid program will ever produce a run-time type failure.

A type rule is a validity constraint involving the typesassociated with program elements.

A validity constraint for a programming language is aboolean condition applicable to any syntactically legalprogram text in the language.


Precise definitions

An object-oriented program is class-level-valid if itsatisfies the following properties:

In every assignment x := y(or argument passing),type of y conforms to type of x.

In every feature call x.f(…)(qualified), f is anexported feature of the class of x.

Without catcalls, any class-level-valid program would betype-safe!


The issue: flexibility vs safety

Find a type system that:

Supports covariance and genericity Permits full static type checking

Stated differently: Disprove the “Pierre America conjecture” that one can

have at most two of polymorphic substitution,covariance, and static type checking

Fix the “holes” in Eiffel’s type system


A typical covariance situation

AR RAY ED _

BOAT

S TAC KCAT

Inherits

Client

captain

sail (...)

sail (...)

repair_second_hull

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


Original class

class BOAT feature

captain: SKIPPER-- Skipper assigned to this boat

sail (c: SKIPPER) is-- Appoint c as captain of this boat.

requirec /= Void

do captain := c

ensurecaptain = c

endend

AR RAY ED _

BOAT

S TAC KCAT

captain

sail (...)

sail (...)

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


Original class (simplified)

class BOAT feature

captain: SKIPPER

sail (c: SKIPPER) isdo

captain := cend

end

ARRAYED_

BOAT

STACKCAT

captain

sail (...)

sail (...)ARRAYED_

SKIPPER

STACKCAT_

SKIPPERcaptain


Heir class

class CAT inheritBOAT

redefinecaptain, sail

end

feature

captain: CAT_SKIPPER

sail (c: CAT_SKIPPER) isdo

captain := cend

end

AR RAY ED _

BOAT

S TAC KCAT

captain

sail (...)

sail (...)

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


Original class, using anchored type

class BOAT feature

captain: SKIPPER

sail (c: like captain) isdo

captain := cend

end

No explicit redefinition necessary for sailin CAT (see next)

AR RAY ED _

BOAT

S TAC KCAT

captain

sail (...)

sail (...)

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


Heir class

classCAT

inherit

BOATredefine

captainend

feature


end


Static typing vs. dynamic binding

x.f

Static typing: ensures that there is AT LEAST ONEFEATURE

Dynamic binding: ensures that it is THE RIGHT FEATURE


Catcalls

boat1: BOAT; cat1: CATskipper1: SKIPPER; cat_skipper1: CAT_SKIPPER...boat1 := cat1...boat1.sail (skipper1)

The captain of this catamaran is now a plain SKIPPER!

Might try to do captain.repair_second_hull (see next)

captain

(SKIPPER)(CAT)

“Ticking bomb”


Catcallsclass

BOATfeature

do_maintenance isdo -- Something here.end

end

feature do_maintenance is do

captain.repair_second_hull endend

class CAT inherit BOAT redefine do_maintenance end


Catcall situation

ARRAYED_

BOAT

STACKCAT

captain

sail (...)

sail (...)repair_second_hull

ARRAYED_

SKIPPER

STACKCAT_

SKIPPERcaptain


Consequences of a catcall

Crash?

Security attack?


Catcalls: source #2 — Genericity

skipper_list: LIST [SKIPPER]cat_skipper_list: LIST [CAT_SKIPPER]...skipper_list := cat_skipper_list

skipper_list.extend (skipper1)

cat_skipper1 := cat_skipper_list.last


Catcalls: source #3 — Descendant hiding

class RECTANGLE inheritPOLYGON

export{NONE}

add_vertex end...

end

poly1 := rect1...poly1.add_vertex (...)


CAT

Changed Availability or Type


Pierre America, 1990

At most two of:

Polymorphic substitution

Covariance

Static type checking


Previous solutions: novariance

C++, Java, .NET...

Eliminates the problem (obviously)

Forces programmers to do the conversions themselves

May result in brittle code


Previous solutions: contravariance

Results specialized, argumentsgeneralized

Solves the problem

Only problem: doesn’t matchpractical needs

The world seems to be covariant.

AR RAY ED _

BOAT

S TAC KCAT

captain

sail (...)

sail (...)

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


Previous solutions: catch catcalls

Generate code to check argumentsCause exception if wrong typeAvoids the security issue

Disadvantages: Performance penalty in all cases Forces issue on client! No easy way to force client to handle exception Exception too drastic


Previous solutions: Overloading

Consider that redefinition creates a new variant of the routine butdoesn’t obliterate the previous one.

Name resolution combines dynamic binding and overloading. Semanticrules can be devised (Giuseppe Castagna, ENS Paris)

Doesn’t seem compatible with goals of O-O programming

AR RAY ED _

BOAT

S TAC KCAT

captain

sail (...)

sail (...)

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


Previous solutions: system-level validity

Considering all assignments, compute dynamic type set(DTS) of any variable x.If there is an assignment x := y, or a correspondingargument passing, all elements of DTS of y are also in theDTS of x.

No attempt at control flow analysis Fixpoint algorithm Helps with optimization

Disadvantages: Pessimistic Not incremental Difficulty of giving precise diagnostics


Previous solutions: class-level validity

If there is an assignment x := y and y is of a differenttype from x, or (recursively) y is polymorphic, consider xpolymorphic.Any formal routine argument is polymorphicDisallow x. r (...) if x is polymorphic and r is a CATroutine.Local information, all incrementalDisadvantages:

Pessimistic Difficulty of giving precise diagnostics


Recent Eiffel developments

Tuples

Expanded inheritance


Tuple types and tuples

TUPLE [X, Y, Z]Denotes sequences of at least three elements, first of

type X, second of type Y, third of type Z

Individual tuple: [x1, y1, z1]

Conformance relations

TUPLE [X, Y, Z] TUPLE [X, Y]


Expanded inheritance

class C inheritA

expanded B

feature...

end

No polymorphism permitted:a1 := c1 -- OK

b1 := c1 -- Not permitted

C

B


The new solution (1)

Covariance etc. OK with expanded inheritance

Covariance also OK with non-exported features

x.f(a) -- Qualified

f(a) -- Unqualified


The new solution (2)

Allow covariant redefinition even with polymorphism!

Replacement (“recast”) must be provided

Also applies to generic case


Covariant cats

class CAT inheritBOAT

redefinecaptain, sail

end

feature


sail (c: CAT_SKIPPER) isrecast

trained_as_cat_skipperdo

captain := cend

end

AR RAY ED _

BOAT

S TAC KCAT

captain

sail (...)

sail (...)

A RRA YED _

SKIPPER

STA CK

CAT_SKIPPER

captain


A recast function

trained_as_cat_skipper (s: SKIPPER): CAT_SKIPPER is-- Version of skipper s reborn as cat skipper

requireexists: s /= Void

docreate Result.train_skipper (s)

end


In CAT_SKIPPER

class CAT_SKIPPER inheritSKIPPER

createmake_from_skipper

feature -- Initializationtrain_skipper (s: SKIPPER) is

requires /= Voids.trained_as_cat_skipper

do…

endend


The latest…

No more recast function

Use exceptions instead

sail (c: CAT_SKIPPER) isdo

captain := crescue

… Can use c …end


The multi-argument case

r (x: TYPE1 ; y: TYPE2; z: TYPE3) isrecast

transformdo

...end

withtransform (x: OLD1 ; y: OLD2; z: OLD3):

TUPLE [TYPE1, TYPE2, TYPE3] isdo

...end


The generic case

In C [G], if there is a routine

r (x: G)

it must have a recast clause!


Possible criticism

Creates a copy

What if LIST of catamarans


The descendant hiding case

Expanded inheritance works, of course

More flexibility: still under discussion


More work

ImplementAnalyze benefits and disadvantages furtherStudy real softwareFormalize through a mathematical model, proveSolve descendant hiding issue


Some tentative conclusions

Flexibility can be reconciled with safety

No need to choose betweenanarchy and “bondage and discipline”

Static typing is practical

Language design is neededLanguage design is funCommittees work!Don’t sail a catamaran unless you know how to

object-oriented software construction bertrand meyer lesson...

Documents