object-oriented software construction bertrand meyer lesson 21

47
Chair of Software Engineering Object-Oriented Software Construction Bertrand Meyer Lesson 21 Last update: 25 May 2004 Type issues, covariance and catcalls

Upload: dewitt

Post on 06-Jan-2016

31 views

Category:

Documents


3 download

DESCRIPTION

Object-Oriented Software Construction Bertrand Meyer Lesson 21. Type issues, covariance and catcalls. Last update: 25 May 2004. What’s special about this lecture. Mix of: Fundamental concepts Unsolved issues Recent proposal. Flexibility vs. safety. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Chair of Software Engineering

Object-Oriented Software ConstructionBertrand Meyer

Lesson 21

Last update: 25 May 2004

Type issues, covariance and catcalls

Page 2: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20042 Chair of Software Engineering

What’s special about this lecture

Mix of:

Fundamental concepts Unsolved issues Recent proposal

Page 3: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20043 Chair of Software Engineering

Flexibility vs. safety

Expressive power (no “bondage and discipline” language)

Protection against crashes and attacks

Page 4: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20044 Chair of Software Engineering

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”

Page 5: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20045 Chair of Software Engineering

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

Page 6: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20046 Chair of Software Engineering

Basic type rules in typed O-O languages

Eiffel, Java, .NET...

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 an exported feature of the class of x.

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

Page 7: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20047 Chair of Software Engineering

Terminology

Typed vs untyped languages

More accurate:

Statically typed, vs Dynamically typed

Page 8: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20048 Chair of Software Engineering

Typing is always pessimistic

Invalid in Pascal:

var n: INTEGER

n := 0.0

if 0 > 1 thenbegin

n := 0.0end

Page 9: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 20049 Chair of Software Engineering

The basic goal

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

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

A validity constraint for a programming language is a boolean condition applicable to any syntactically legal program text in the language.

Page 10: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200410 Chair of Software Engineering

Precise definitions

An object-oriented program is class-level-valid if it satisfies 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 an exported feature of the class of x.

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

Page 11: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200411 Chair of Software Engineering

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

Page 12: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200412 Chair of Software Engineering

A typical covariance situation

A R R A Y E D _

BOAT

S T A C KCAT

Inherits

Client

captain

sail (...)

sail (...)repair_second_hull

A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 13: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200413 Chair of Software Engineering

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

A R R A Y E D _

BOAT

S T A C KCAT

captain

sail (...)

sail (...)A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 14: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200414 Chair of Software Engineering

Original class (simplified)

class BOAT feature

captain: SKIPPER

sail (c: SKIPPER) isdo

captain := cend

end

ARRAYED_

BOAT

STACKCAT

captain

sail (...)

sail (...)

ARRAYED_

SKIPPER

STACKCAT_

SKIPPER

captain

Page 15: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200415 Chair of Software Engineering

Heir class

class CAT inheritBOAT

redefinecaptain, sail

end

feature

captain: CAT_SKIPPER

sail (c: CAT_SKIPPER) isdo

captain := cend

end

A R R A Y E D _

BOAT

S T A C KCAT

captain

sail (...)

sail (...)A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 16: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200416 Chair of Software Engineering

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)

A R R A Y E D _

BOAT

S T A C KCAT

captain

sail (...)

sail (...)A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 17: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200417 Chair of Software Engineering

Heir class

classCAT

inherit

BOATredefine

captainend

feature

captain: CAT_SKIPPER

end

Page 18: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200418 Chair of Software Engineering

Static typing vs. dynamic binding

x.f

Static typing: ensures that there is AT LEAST ONE FEATURE

Dynamic binding: ensures that it is THE RIGHT FEATURE

Page 19: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200419 Chair of Software Engineering

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”

Page 20: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200420 Chair of Software Engineering

Catcallsclass

BOAT feature

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

Page 21: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200421 Chair of Software Engineering

Catcall situation

ARRAYED_

BOAT

STACKCAT

captain

sail (...)

sail (...)repair_second_hull

ARRAYED_

SKIPPER

STACKCAT_

SKIPPER

captain

Page 22: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200422 Chair of Software Engineering

Consequences of a catcall

Crash?

Security attack?

Page 23: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200423 Chair of Software Engineering

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

Page 24: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200424 Chair of Software Engineering

Catcalls: source #3 — Descendant hiding

class RECTANGLE inheritPOLYGON

export{NONE}

add_vertex end...

end

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

Page 25: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200425 Chair of Software Engineering

CAT

Changed Availability or Type

Page 26: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200426 Chair of Software Engineering

Pierre America, 1990

At most two of:

Polymorphic substitution

Covariance

Static type checking

Page 27: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200427 Chair of Software Engineering

Previous solutions: novariance

C++, Java, .NET...

Eliminates the problem (obviously)

Forces programmers to do the conversions themselves

May result in brittle code

Page 28: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200428 Chair of Software Engineering

Previous solutions: contravariance

Results specialized, arguments generalized

Solves the problem

Only problem: doesn’t match practical needs

The world seems to be covariant.

A R R A Y E D _

BOAT

S T A C KCAT

captain

sail (...)

sail (...)A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 29: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200429 Chair of Software Engineering

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

Page 30: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200430 Chair of Software Engineering

Previous solutions: Overloading

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

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

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

A R R A Y E D _

BOAT

S T A C KCAT

captain

sail (...)

sail (...)A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 31: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200431 Chair of Software Engineering

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 corresponding argument passing, all elements of DTS of y are also in the DTS of x.

No attempt at control flow analysis Fixpoint algorithm Helps with optimization

Disadvantages: Pessimistic Not incremental Difficulty of giving precise diagnostics

Page 32: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200432 Chair of Software Engineering

Previous solutions: class-level validity

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

Pessimistic Difficulty of giving precise diagnostics

Page 33: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200433 Chair of Software Engineering

Recent Eiffel developments

Tuples

Expanded inheritance

Page 34: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200434 Chair of Software Engineering

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]

Page 35: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200435 Chair of Software Engineering

Expanded inheritance

class C inheritA

expanded B

feature...

end

No polymorphism permitted:a1 := c1 -- OKb1 := c1 -- Not permitted

C

B

Page 36: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200436 Chair of Software Engineering

The new solution (1)

Covariance etc. OK with expanded inheritance

Covariance also OK with non-exported features

x.f(a) -- Qualified

f(a) -- Unqualified

Page 37: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200437 Chair of Software Engineering

The new solution (2)

Allow covariant redefinition even with polymorphism!

Replacement (“recast”) must be provided

Also applies to generic case

Page 38: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200438 Chair of Software Engineering

Covariant cats

class CAT inheritBOAT

redefinecaptain, sail

end

feature

captain: CAT_SKIPPER

sail (c: CAT_SKIPPER) isrecast

trained_as_cat_skipperdo

captain := cend

end

A R R A Y E D _

BOAT

S T A C KCAT

captain

sail (...)

sail (...)A RRA YED _

SKIPPER

S TA CKCAT_

SKIPPER

captain

Page 39: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200439 Chair of Software Engineering

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

Page 40: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200440 Chair of Software Engineering

In CAT_SKIPPER

class CAT_SKIPPER inheritSKIPPER

createmake_from_skipper

feature -- Initializationtrain_skipper (s: SKIPPER) is

requires /= Voids.trained_as_cat_skipper

do…

endend

Page 41: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200441 Chair of Software Engineering

The latest…

No more recast function

Use exceptions instead

sail (c: CAT_SKIPPER) isdo

captain := crescue

… Can use c …end

Page 42: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200442 Chair of Software Engineering

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] is do

...end

Page 43: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200443 Chair of Software Engineering

The generic case

In C [G], if there is a routine

r (x: G)

it must have a recast clause!

Page 44: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200444 Chair of Software Engineering

Possible criticism

Creates a copy

What if LIST of catamarans

Page 45: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200445 Chair of Software Engineering

The descendant hiding case

Expanded inheritance works, of course

More flexibility: still under discussion

Page 46: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200446 Chair of Software Engineering

More work

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

Page 47: Object-Oriented Software Construction Bertrand Meyer Lesson 21

Programming in the Large, 200447 Chair of Software Engineering

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