Data Groups: Specifying the Modification of Extended State
Total Page：16
File Type：pdf, Size：1020Kb
Data groups: Specifying the modification of extended state K. Rustan M. Leino Compaq Systems Research Center 130 Lytton Ave., Palo Alto, CA 94301, U.S.A. www.research.digital.com/SRC/people/Rustan-Leino [email protected] Abstract not use the code in a method’scallers when reasoning about the method implementation,and one doesnot use the imple- This paper explores the interpretation of specificationsin the mentation when reasoningabout the calls. context of an object-oriented programming language with To be useful to the caller, it is important that the postcon- subclassingand method overrides. In particular, the paper dition of a method detail what variables the method doesnot considersannotations for describing what variablesa method change. But since the scope of the caller can include vari- may changeand the interpretation of theseannotations. The ables that are not visible in the scope where the method is paper shows that there is a problem to be solved in the spec- declared and specified,it is not possible to explicitly list all ification of methodswhose overrides may modify additional unchangedvariables in the method’spostcondition. Instead, state introduced in subclasses. As a solution to this prob- the annotation languagemust include someform of syntactic lem, the paper introduces data groups, which enable mod- shorthand(“sugar”) whose interpretation as part of the post- ular checking and rather naturally capture a programmer’s condition is a function of the scopein which it is interpreted. design decisions. A nice construct for this is the modifies clause, which lists those variablesthat the method is allowed to modify, thereby 0 Introduction specifying that the method does not modify any other vari- ables [GH93]. For example,suppose that the specification of Specifications help in the documentation of computer pro- a method m occurs in a scopewhere two variables, x and y , grams. Ideally, specificationscan be used by a mechanical are visible, and that the specification includes the modifies program analyzer to check the body of a method against its CIaUse specification, attempting to find errors. The Extended Static modifies x Checkers for Modula-3 [DLNS98, L.N98b, Det961and for If m is called from a scopewhere, additionally, a variable z Java [ESC], which work on object-oriented programs, are is visible, then the caller’s interpretation (“desugaring”) of examplesof such program checkers. the specification says that the call may possibly modify x , This paper concerns the spectication of methods. A but leavesboth y and z unchanged. method specification is a contract between the implemen- The fact that a modifies clauseis interpreted differently tation of a method and its callers. As such, it includes a in different scopesraises a concern about modular sound- precondition, which documentswhat a caller must establish nem &ei95]. For the purposeof this paper, modular sound- before invoking the method. Consequently, the implemen- ness means that the implementation, which is checked to tation can assumethe precondition on entry to the method meet the specification as interpreted in the scope contain- body. A method specification also includes a postcondition, ing the method body, actually lives up to a caller’s expecta- which documents what the implementation must establish tions, which are basedon the specification as interpreted in on exit. Consequently,the caller can assumethe postcondi- the scopeof the call. A consequenceof modular soundness tion upon return from the method invocation. When reason- is that one can check a classeven in the absenceof its future ing about method implementations and calls, only the con- clients and subclasses. tract given by the specification is used. That is, one does This paper explores the interpretation of specifications in the context of an object-orientedprogramming language Permlssnn to make dlgttal or hard copies of all or part of this work for personal or classroom use ,s granted wlthout fee prowded that with subclassingand methodoverrides, for examplelike Java. copes are not made or distributed lor proflt or commercial advan- In particular, I consider annotations for describing what a tage and that copnes bear the notice and the full c~tat~o” on the first page. la copy otherwse. to republwh, to post on servers or to method may change and the interpretation of these annota- redlstnbute to Iwts, reqwres prwr specific perm~sston and/or a fee. tions. I show that there is a problem to be solved in the OOPSLA ‘98 lo/98 Vancouver, B.C. 0 1998 ACM l-581 13.005.8/98/0010...$5.00 144 specification of methodswhose overrides may modify addi- meetsits specificationcomes down to checking that it mod- tional state introduced in subclasses.As a solution to this ifies only those variables that it is permitted to modify. The problem, I introduce data groups, which adhere to modular implementationsof the updatePosition, updatecolor, soundnessand rather naturally capture a programmer’sde- and draw methodsare no-ops, so they trivially satisfy their sign decisions. specifications. The update method invokes the other two For simplicity, I restrict my attention to the operations updatemethods, whose modifies clausessay they may mod- on only one object, the implicit self parameter. Neverthe- ify x, y, and co1 . So update in effect modifies x, y, and less, becauseof inheritance and method overriding, the im- col, and this is exactly what its specification allows. We plementationsof the methodsof this object may be found in conclude that the methodsin class Sprite meet their spec- superclassesand subclassesof the class being checked. ifications. Let us now consider a subclass Hero of Sprite, rep- 1 Extending the state of a superclass resenting the hero of the game. The hero can move about, and hence the Hero class provides its own implementation To illustrate the problem, I introduce a simplified exampleof of the updateposition method by overriding this method. a computerarcade game--an excellent application of object- The next position of the hero is calculated from the hero’s oriented programming indeed. velocity and acceleration,which are representedas instance The design centersaround sprites. A sprite is a gameob- variables. The Hero class is declaredas follows: ject that appearssomewhere on the screen. In this simple class Hero extends Sprite { example, every sprite has a position, a color, and methods int dx, dy; to update these. The main program, which I will not show, int ddx, ddy; essentially consists of a loop that performs one iteration per void updatePosition() video frame. Each iteration works in two phases. The fist { x += dx + ddx/2; y += dy + ddy/2; phaseinvokes the update methodon each sprite, which up- dx += ddx; dy += ddy; dates the sprite’s position, color, and other attributes. The 1 secondphase invokes the draw methodon eachsprite, which . rendersthe sprite on the screen. 1 Here is the declaration of class Sprite, in which the methodshave been annotatedwith modifies clauses: The Hero implementation of updatePosition increases x and y by appropriateamounts (Ad = vo . t + l/z . a - t2 class Sprite { where r = 1). In addition, it updatesthe velocity according int x, y; to the current acceleration. (Omitted from this example is void updatePosition /* modifies x, y */ the updateof acceleration,which is computed according to ( 1 the gameplayer’s joystick movements.) It seemsnatural to int col; update the velocity in the method that calculates the new void updateColor() I* modifies co1 *I position, but the specilication of updatePosition (given I 1 in class Sprite) allows only x and y to be modified, not dx void update ( ) I* modifies x, y, co1 *I and dy which are not even defined in class Sprite. (If the { updatePosition(); updateColor( ); } updateof dx and dy instead took place in method update, void draw0 /* modifies (nothing) */ there would still be a problem, since the modifies clause of ( 1 update also does not include these variables.) 1 As evidencedin this example,the reasonfor overriding a The default update method invokes the updatePosition method is not just to changewhat the method does algorith- and updatecolor methods, whose default implementations micly, but also to change what data the method updates. In do nothing. Any of these methods can be overridden in fact, the main reasonfor designing a subclassis to introduce Sprite subclasses. For example, a moving sprite that subclass-specificvariables, and it is the uses and updatesof never changescolors would override the updateposition such variables that necessitatebeing able to override meth- method, a stationary sprite whose color changesover time ods. For example, class Sprite was designed with the in- would override the updatecolor method, and a sprite that tention that subclassesbe able to add sprite attributes and adds further attributes that need to be updatedoverrides the update these in appropriatemethods. So how does one in a update method and possibly also the updatePos it ion and superclasswrite the specificationof a method such that sub- updateColor methods. classescan extend the superclass’sstate (that is, introduce Since the speciticationsI have given in the example show additional variables) and override the method to modify this only modifies clauses, checking that an implementation extendedstate? 145 2 Three straw man proposals constant, without taking up any per-object storage. This de- sign tradesquick accessof an attribute for flexibility in how In this section, I discuss three proposals that I often