$2.2 METHOD AND LANGUAGE 29 attached to an object representing an object of type BUOy,a class which does not inherit from BOA7. It should be possible to attach entities (names in the software texts representing run-time objects)to run-time objects of various possible types, under the control of the inheritance-based type system. Dynamic binding The combination of the last two mechanisms mentioned,redefinition and polymorphism, immediately suggests the next one.Assume a call whose target is a polymorphic entity, for example a call to the feature turn on an entity declared of type BO47.The various descendants of BO4T may have redefined the feature in various ways.Clearly,there must be an automatic mechanism to guarantee that the version of rurn will always be the one deduced from the actual object's type,regardless of how the entity has been declared.This property is called dynamic binding. Calling a feature on an entity should always trigger the feature corresponding to the type of the attached run-time object,which is not necessarily the same in different executions of the call. Dynamic binding has a major influence on the structure of object-oriented applications,as it enables developers to write simple calls(meaning,for example,"call feature turn on entity my boat")to denote what is actually several possible calls depending on the corresponding run-time situations.This avoids the need for many of the repeated tests ("Is this a merchant ship?Is this a sports boat?")which plague software written with more conventional approaches. Run-time type interrogation Object-oriented software developers soon develop a healthy hatred for any style of computation based on explicit choices between various types for an object.Polymorphism and dynamic binding provide a much preferable alternative.In some cases,however,an object comes from the outside,so that the software author has no way to predict its type with certainty.This occurs in particular if the object is retrieved from external storage, received from a network transmission or passed by some other system. The software then needs a mechanism to access the object in a safe way,without violating the constraints of static typing.Such a mechanism should be designed with care, so as not to cancel the benefits of polymorphism and dynamic binding. The assignment attempt operation described in this book satisfies these requirements.An assignment attempt is a conditional operation:it tries to attach an object to an entity;if in a given execution the object's type conforms to the type declared for the entity,the effect is that ofa normal assignment;otherwise the entity gets a special"void"§2.2 METHOD AND LANGUAGE 29 attached to an object representing an object of type BUOY, a class which does not inherit from BOAT. Dynamic binding The combination of the last two mechanisms mentioned, redefinition and polymorphism, immediately suggests the next one. Assume a call whose target is a polymorphic entity, for example a call to the feature turn on an entity declared of type BOAT. The various descendants of BOAT may have redefined the feature in various ways. Clearly, there must be an automatic mechanism to guarantee that the version of turn will always be the one deduced from the actual object’s type, regardless of how the entity has been declared. This property is called dynamic binding. Dynamic binding has a major influence on the structure of object-oriented applications, as it enables developers to write simple calls (meaning, for example, “call feature turn on entity my_boat”) to denote what is actually several possible calls depending on the corresponding run-time situations. This avoids the need for many of the repeated tests (“Is this a merchant ship? Is this a sports boat?”) which plague software written with more conventional approaches. Run-time type interrogation Object-oriented software developers soon develop a healthy hatred for any style of computation based on explicit choices between various types for an object. Polymorphism and dynamic binding provide a much preferable alternative. In some cases, however, an object comes from the outside, so that the software author has no way to predict its type with certainty. This occurs in particular if the object is retrieved from external storage, received from a network transmission or passed by some other system. The software then needs a mechanism to access the object in a safe way, without violating the constraints of static typing. Such a mechanism should be designed with care, so as not to cancel the benefits of polymorphism and dynamic binding. The assignment attempt operation described in this book satisfies these requirements. An assignment attempt is a conditional operation: it tries to attach an object to an entity; if in a given execution the object’s type conforms to the type declared for the entity, the effect is that of a normal assignment; otherwise the entity gets a special “void” It should be possible to attach entities (names in the software texts representing run-time objects) to run-time objects of various possible types, under the control of the inheritance-based type system. Calling a feature on an entity should always trigger the feature corresponding to the type of the attached run-time object, which is not necessarily the same in different executions of the call