$17.2 STATIC TYPING:WHY AND HOW 619 It seems difficult to accept claims of static typing if at any stage the developer can eschew the type rules through casts.Accordingly,the rest of this chapter will assume that the type system is strict and allows no casts. You may have noted that assignment attempts,mentioned above as an essential component of a realistic type system,superficially resemble casts.But there is a fundamental difference:an assignment attempt does not blindly force a different type;it tries a candidate type,and enables the software to check whether the object actually matches that type.This is safe,and indispensable in some circumstances.The C++ literature sometimes includes assignment attempts ("downcasts")in its definition of casts;clearly,the above prohibition of casts only covers the harmful variant,and does not extend to assignment attempts. Typing and binding:avoiding the confusion Although as a reader of this book you will have no difficulty distinguishing static typing from static binding,you may meet people who confuse the two notions.This may be due in part to the influence of Smalltalk,whose advocacy of a dynamic approach to both typing and binding may leave the inattentive observer with the incorrect impression that the answer to both questions must be the same.(The analysis developed in this book suggests that to achieve reliability and flexibility it is preferable to combine dynamic binding with static typing.)Let us carefully compare the two concepts. Both have to do with the semantics of the Basic Construct xf(arg);they cover the two separate questions that it raises: Typing and binding .Typing question:When do we know for sure that at run time there will be an operation corresponding to /and applicable to the object attached to x(with the argument arg)? Binding question:Which operation will the call execute? Typing addresses the existence of at least one operation;binding addresses the choice of the right one among these operations,if there is more than one candidate. In object technology: The typing question follows from polymorphism:since x may denote run-time objects of several possible types,we must make sure that an operation representing f is available in all cases. The binding question follows from redeclaration:since a class can change an inherited feature -as with RECTANGLE redefining perimeter inherited from POLYGON-there may be two or more operations all vying to be the one representing for a particular call. Both answers can be dynamic,meaning at execution time,or static,meaning before execution.All four possibilities appear in actual languages:§17.2 STATIC TYPING: WHY AND HOW 619 It seems difficult to accept claims of static typing if at any stage the developer can eschew the type rules through casts. Accordingly, the rest of this chapter will assume that the type system is strict and allows no casts. You may have noted that assignment attempts, mentioned above as an essential component of a realistic type system, superficially resemble casts. But there is a fundamental difference: an assignment attempt does not blindly force a different type; it tries a candidate type, and enables the software to check whether the object actually matches that type. This is safe, and indispensable in some circumstances. The C++ literature sometimes includes assignment attempts (“downcasts”) in its definition of casts; clearly, the above prohibition of casts only covers the harmful variant, and does not extend to assignment attempts. Typing and binding: avoiding the confusion Although as a reader of this book you will have no difficulty distinguishing static typing from static binding, you may meet people who confuse the two notions. This may be due in part to the influence of Smalltalk, whose advocacy of a dynamic approach to both typing and binding may leave the inattentive observer with the incorrect impression that the answer to both questions must be the same. (The analysis developed in this book suggests that to achieve reliability and flexibility it is preferable to combine dynamic binding with static typing.) Let us carefully compare the two concepts. Both have to do with the semantics of the Basic Construct x ● f (arg); they cover the two separate questions that it raises: Typing addresses the existence of at least one operation; binding addresses the choice of the right one among these operations, if there is more than one candidate. In object technology: • The typing question follows from polymorphism: since x may denote run-time objects of several possible types, we must make sure that an operation representing f is available in all cases. • The binding question follows from redeclaration: since a class can change an inherited feature — as with RECTANGLE redefining perimeter inherited from POLYGON — there may be two or more operations all vying to be the one representing f for a particular call. Both answers can be dynamic, meaning at execution time, or static, meaning before execution. All four possibilities appear in actual languages: Typing and binding • Typing question: When do we know for sure that at run time there will be an operation corresponding to f and applicable to the object attached to x (with the argument arg)? • Binding question: Which operation will the call execute?