618 TYPING $17.2 example,that a certain entity takes its values between 10 and 20,no type mechanism will enable you to state that i must be either in that interval or negative,and always twice as much as j.Here class invariants come to the rescue,by letting you specify exactly what you need,however sophisticated the constraint. Anchored declarations are essential in practice to avoid redeclaration avalanche. “ANCHORED By declaring y:like x you make sure that y will follow any redeclaration of the type ofx DECLARATION" in a descendant.Without this mechanism developers would be endlessly redeclaring 167,page599. routines for type purposes only. Anchored declarations are a specific case of our last required language mechanism: covariance,which will be discussed in more detail later in this chapter. A practical property of the environment is also essential:fast incremental recompilation.When you write a system or(more commonly)modify an existing system, you will want to see the effect soon.With static typing you must first let the compiler re- typecheck the system.Traditional compiling techniques require recompiling the whole system (and going through a linking process),the time may be painfully long,especially for a proportionally small change to a large system.This phenomenon has been a major a contrario argument for interpreted approaches,such as those of early Lisp and Smalltalk environments,which execute systems with no or little processing,hence no type checking. But modern compiler technology removes this argument.A good compiler will detect what has changed since the last compilation,and reprocess only that part,keeping the recompilation time small-and proportional to the size of the change,not of the system. The Melting Ice Technology described in the last chapter of this book achieves this goal, typically permitting recompilation in a matter of seconds after a small change even to a large system. “A little bit typed”? It was noted above that we should aim for a strong form of static typing.This means that we should avoid any loopholes in the static requirements-or,if any such loopholes remain,identify them clearly,if possible providing tools to flag any software using them. The most common loophole,in languages that are otherwise statically typed,is the presence of conversions that disguise the type of an entity.In C and its derivatives, conversions are called "casts"and follow a simple syntax:(OTHER TYPE)x denotes the value ofx presented to the compiler as if it were of type OTHER TYPE;there are few limitations on what that type may be,regardless ofx's actual type. Such mechanisms evade the constraints of type checking;casting is indeed a pervasive feature of C programming,including in the ANSI C variant(which is"more" typed than its precursor,the so-called Kernighan and Ritchie version).Even in C++, examination of published software shows that casts,although less frequent,remain an accepted and possibly indispensable occasional practice.618 TYPING §17.2 example, that a certain entity takes its values between 10 and 20, no type mechanism will enable you to state that i must be either in that interval or negative, and always twice as much as j. Here class invariants come to the rescue, by letting you specify exactly what you need, however sophisticated the constraint. Anchored declarations are essential in practice to avoid redeclaration avalanche. By declaring y: like x you make sure that y will follow any redeclaration of the type of x in a descendant. Without this mechanism developers would be endlessly redeclaring routines for type purposes only. Anchored declarations are a specific case of our last required language mechanism: covariance, which will be discussed in more detail later in this chapter. A practical property of the environment is also essential: fast incremental recompilation. When you write a system or (more commonly) modify an existing system, you will want to see the effect soon. With static typing you must first let the compiler re￾typecheck the system. Traditional compiling techniques require recompiling the whole system (and going through a linking process); the time may be painfully long, especially for a proportionally small change to a large system. This phenomenon has been a major a contrario argument for interpreted approaches, such as those of early Lisp and Smalltalk environments, which execute systems with no or little processing, hence no type checking. But modern compiler technology removes this argument. A good compiler will detect what has changed since the last compilation, and reprocess only that part, keeping the recompilation time small — and proportional to the size of the change, not of the system. The Melting Ice Technology described in the last chapter of this book achieves this goal, typically permitting recompilation in a matter of seconds after a small change even to a large system. “A little bit typed”? It was noted above that we should aim for a strong form of static typing. This means that we should avoid any loopholes in the static requirements — or, if any such loopholes remain, identify them clearly, if possible providing tools to flag any software using them. The most common loophole, in languages that are otherwise statically typed, is the presence of conversions that disguise the type of an entity. In C and its derivatives, conversions are called “casts” and follow a simple syntax: (OTHER_TYPE) x denotes the value of x presented to the compiler as if it were of type OTHER_TYPE; there are few limitations on what that type may be, regardless of x’s actual type. Such mechanisms evade the constraints of type checking; casting is indeed a pervasive feature of C programming, including in the ANSI C variant (which is “more” typed than its precursor, the so-called Kernighan and Ritchie version). Even in C++, examination of published software shows that casts, although less frequent, remain an accepted and possibly indispensable occasional practice. “ANCHORED DECLARATION”, 16.7, page 599