Type Migration

I don't know if there is a better term in the literature... but TypeMigration occurs when an object which is initially of one type changes (through some operation) to an object of a different type. Many languages don't have this--an object's type is generally considered an immutable property of the object.

Useful in the real world; as many physical objects change state over time, and some of these state changes are significant. (Indeed, it can be argued that the distinction between an object's "type" and its "state" is artificial--ThereAreNoTypes). That said, TypeMigration is difficult in languages with StaticTyping; even many dynamically-typed languages don't let you add/delete features from an object after construction.

For instance, when an Integer counter overflows in SchemeLanguage, it is automatically type-migrated to a BigNum, and the counter keeps on counting.

This is similar, but not true TypeMigration; Integers and BigNums are both ValueObjects, so what is happening here is the addition function is returning an object of a different type.

(That said--the distinction between type and state is artificial mainly from a semantic point of view; from an implementation point of view the distinction becomes significant).

If you think of an object's type as its collection of behaviors, the RubyCoerce page tells a saga of what might be considered TypeMigration. The saga ends with variations of the subtraction operator for a Rectangle getting swapped.

Related to this is the type migration of values in relational operators. Comparing two reals for equality results in a boolean. No; that's just the behavior of the operator in question; neither of the reals becomes a boolean. Only the result is a boolean.

So you'd say that multiplying two floats together doesn't retain the original type, it's "just" the behavior of the operator? What are you looking for here, a definition wherein the value remains identical but the type changes? (This is on thin ice without a formal definition of "identical value".)

I'll buy that, but are we now using private terminology, or is "type migration" with this definition some kind of widely used phrase in the industry?

(I'm familiar with the Scheme/Lisp mechanism, but I don't recall if this phrases is standardly used to describe it.)

Also related, but not identical, is TypeCoercion?--when an object of one type T1 is used in a context where an object of another type T2 is expected, and the language than creates a new object of type T2 which is somehow equivalent to the object of type T1.

Also see SystemMutation and RuntimeTypeMutability, TypeRefinement, SchemaEvolution.