1 / 57

Avoid a void

Avoid a void. Bertrand Meyer With major contributions by Emmanuel Stapf & Alexander Kogtenkov (Eiffel Software). Basic O-O operation. x . f ( args ). Semantics: apply the feature f , with given args if any, to the object to which x is attached. … and basic issue studied here:.

gordy
Download Presentation

Avoid a void

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Avoid a void Bertrand Meyer With major contributions by Emmanuel Stapf &Alexander Kogtenkov(Eiffel Software)

  2. Basic O-O operation • x.f (args) Semantics: apply the feature f, with given args if any, to the object to which x is attached … and basic issue studied here: How do we guarantee that x will always be “attached” to an object? (If not, call produces an exception and usually termination)

  3. I call it my billion-dollarmistake. It was the inventionof the null reference in 1965.I was designing the firstcomprehensive type systemfor references in an object-oriented language (ALGOL W).My goal was to ensure that alluse of references should besafe, checked by the compiler.But I couldn't resist the temptation to put in a null reference, because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

  4. Plan Context New language constructs Achieving void safety Current status

  5. - 1 - Context

  6. Source: Patrice Chalin • 44.4% of Eiffel preconditions clauses are of the form • x /= Void

  7. The standards effort • ECMA standard for Eiffel • Approved June 2005, 2nd edition, June 2006 • ISO standard, November 2006 • Mechanism described here is in EiffelStudio 6.3, Nov 2008; libraries fully adapted in 6.4, May 2009

  8. Requirements • Minimal language extension • Statically, completely void safe • Simple for programmer, no mysterious rules • Reasonably simple for compiler • Handles genericity • Doesn’t limit expressiveness • Compatibility or minimum change for existing code • 1st-semester teachability

  9. Lessons from Spec# work • “Spec# stipulates the inference of non-[voidness] for local variables. This inference is performed as a dataflow analysis by the Spec# compiler.” • (Barnett, Leino, Schulte, Spec# paper) x /= Void

  10. Subject: “I had a dream” From:"Eric Bezault" ericb@gobosoft.com To:"ECMA TC49-TG4" Date:Thu, 4 Jun 2009 11:21 Last night I had a dream. I was programming in Eiffel 5.7. The code was elegant. There was no need for defensive programming just by taking full advantage of design by contract. Thanks to these contracts the code was easy to reuse and to debug. I could hardly remember the last time I had a call-on-void-target. It was so pleasant to program with such a wonderful language. This morning when I woke up I looked at the code that had been modified to comply with void-safety. This was a rude awakening. The code which was so elegant in my dream now looked convoluted, hard to follow. It looks like assertions are losing all their power and defensive programming is inviting itself again in the code. […]

  11. - 2 - New language constructs

  12. New constructs Object test Replaces all “downcasting” (type narrowing) mechanisms 2. Type annotations: “attached” and “detachable” New keywords: attached, detachable (Plus: stable.)

  13. The Object Test (full form) • Boolean expression: • attached {T} expasx • Value: True if value ofexpis attached to an object of typeTor conforming • Plus: binds xto that value over scopeof object test Expression Type Name (“Object-Test Local”)

  14. Object Test example • if attached {T} expas x then • … Arbitrary instructions… • x .operation • … Other instructions … • end Scope of x

  15. Object Test variants • attached {T} expasx • attachedexpasx • attached {T} exp • attachedexp Same semantics as exp /= Void

  16. Another example of Object Test scope • from • … • until not attachedexpas xloop • … Arbitrary instructions … • x.some_operation • … Other instructions … • end Scope of x

  17. Object test in contracts • my_routine • require • attachedexpas xand then x.some_property • do • … • end Scope of x

  18. - 3 - Achieving void safety

  19. A success story: static type checking • We allow • x.f (args) • only if we can guarantee that at run time: • The object attached tox, if it exists, has a feature for f, able to handle the args. • Basic ideas: • Accept it only if type of x has a feature f • Assignment x := y requires conformance (based on inheritance) What if x is void?

  20. Generalizing static type checking • The goal (“void safety”): at compile time, allow • x.f (args) • only if we can guarantee that at run time: • x is not void.

  21. The basic rule • x.f (args)is permitted only ifxis attached • where “attached” is a static property • The rest of this discussion is about various ways to ensure that x is attached

  22. Components of the solution • 1.Some patterns guaranteed void-safe • (“Certified Attachment Patterns” or CAPS) • 2. Object test • 3. Attached type (Issue here: initialization) • 4. Rule for generic parameters

  23. Components of the solution • 1.Some patterns guaranteed void-safe • (“Certified Attachment Patterns” or CAPS) • 2. Object test • 3. Attached type (Issue here: initialization) • 4. Rule for generic parameters

  24. Certified Attachment Patterns CAP: a program scheme that guarantees the void-safety of a call

  25. CAP 1: conditional • Consider a variable or expression e • Can this be guaranteed void-safe? • ife/= Voidthen • e.operation • end (Assume eis a variable) other_instructions not assigning toe What aboutmultithreading? (args) Answer: only if eis a local variable! (or formal argument) Not for an attribute, or a general expression.

  26. CAP 2: loop • from • ... • until • x = Void • loop • ... Any instructions not assigning to x... • … (except possibly last instruction) … • end • xmust again be a local variable or a formal argument! A CAP for x

  27. A typical loop, now safe • from • x:=first_element • until • x= Void orelseResult • loop • Result:= (x.item= sought) • x := x.right • end first_element Zurich JFK Logan item right item right item right

  28. CAP 3: check instruction (after) implies (active = Void) after before active "Boston" count count+1 0 1 index Semantics of check a end: compiler must either prove that a holds or generate code that triggers exception if it doesn’t check active/=Void end Consider a class with the invariant and the routine r require notafter do active.some_operation end

  29. The CAP catalog • About 6 CAPs specified in the ECMA standard. Above threearethe most important. • Another example: xin • x /= Voidimpliesx.some_property • Criterion: simple; easy to understand; provably and obviously correct • Need to be approved by committee • Mathematical, machine-checked proofs desirable

  30. CAP variant: stable attributes What aboutmultithreading? not assigning toe other_instructions • OK if e is a “stable attribute”: no routine of the class assigns to it • e : SOME_TYPE • note • stable • attribute • end ife /= Voidthen e.operation end

  31. Components of the solution • 1.Some patterns guaranteed void-safe • (“Certified Attachment Patterns” or CAPS) • 2. Object test • 3. Attached type (Issue here: initialization) • 4. Rule for generic parameters

  32. Using an object test for void safety • if attached {T} expas x then • … Arbitrary instructions… • x .operation • … Other instructions … • end Scope of x

  33. The remaining goal… • Minimize use of Object Test! General but impractical solution: protect every qualified feature call by an Object Test! Instead of exp.operation write ifattached {T} expas xthen x .operation end

  34. Components of the solution • 1.Some patterns guaranteed void-safe • (“Certified Attachment Patterns” or CAPS) • 2. Object test • 3. Attached type (Issue here: initialization) • 4. Rule for generic parameters

  35. Attached and detachable types • For any typeT, a variable declared as just • x: T -- or:x: attachedT • cannot be void! • TypeTis attached • To allow void values, declare • x: detachableT • Type detachableTis detachable

  36. Default policy Attached as a default because of “business objects”, e.g bank accounts, persons, planes… Voidis useful for “Knuthware”, specifically linked structures

  37. The remaining problem… • How to ensure that variables declared of an attached type • x: T • meet that declaration, i.e. can never become void!

  38. Conservation of attachment • In • x := y • or • r (y) -- Where formal argument is x • if type ofxis attached, ymust be attached.

  39. If assignment & argument passing are OK… • … there remains initialization!

  40. The initialization problem • In previous Eiffel: • Basic types initialized to standard values (zero, False, null character) • Otherexpandedtypes must havedefault_createfromANY • References initialized toVoid

  41. Initializing variables Scheme 1: CAP • An attribute is attached if every creation procedure sets it. • A local variable is initialized if the beginning of the routine sets it.

  42. Initializing variables Scheme 1: CAP Scheme 2: Self-initializing attributes

  43. Digression: attributes • bounding_rectangle: RECTANGLE • -- Smallest rectangle including whole of current figure

  44. Digression: attributes with contracts! • bounding_rectangle: RECTANGLE • -- Smallest rectangle including whole of current figure • require • bounded • attribute • ensure • Result.height = height • Result.width = width • Result.lower_left = lower_left • Result.contains (Current) • end

  45. Self-initializing attributes • bounding_rectangle: FIGURE • -- Smallest rectangle including whole of current figure • -- (Computed only if needed) • require • bounded • attribute • createResult.set (lower_left, width, height) • ensure • Result.height = height • Result.width = width • Result.lower_left = lower_left • Result.contains (Current) • end … As before …

  46. Initializing variables Scheme 1: CAP Scheme 2: Self-initializing attributes Scheme 3: Properly set variables What if an attribute is not self-initializing?

  47. Properly set variables • At any place where it is accessed, a variable must be properly set

  48. Components of the solution • 1.Some patterns guaranteed void-safe • (“Certified Attachment Patterns” or CAPS) • 2. Object test • 3. Attached type (Issue here: initialization) • 4. Rule for generic parameters

  49. Variables of a formal generic type In class C [G ], what about variables such as x: G ? Example generic derivations: C [INTEGER ] C [EMPLOYEE ]

  50. Meaning of a formal generic parameter • Constrainedgenericity: classC [G -> T] … • Generic derivation must be C [U], whereUconforms to T • Unconstrainedgenericity: classC [G] • In pre-void-safe Eiffel: abbreviation forclassC [G -> ANY] … • Now: abbreviation forclassC [G -> detachableANY] … • Can also use classC [G -> attachedT]

More Related