[Meyer97] contains a neat chapter with definitions that makes it a lot easier to discuss about programming languages when it comes to typing. Here are the basics.
We should agree on the basic construct of object-oriented computation: the feature call or for SmallTalkers “passing a message to an object” and for Java guys and gals “invoking a method”.
The Basic Construct (feature call)x.f(arg); // [0..n] arguments
Think of a non-trivial class-hierarchy of visual components, a classic example. There is an interface or an deferred (abstract) base class that requires descendants to provide a feature (method) named paint(context). What happens if the compiler does not check that every concrete class has an implementation? We get a type violation at run-time.
Definition: type violation
A run-time type violation (or just type violation for short) occurs in the execution of a call x.f(arg), where x is attached to an object OBJ, if either
(V1) There is no feature corresponding to f and applicable to OBJ.
(V2) There is such a feature, but arg is not an acceptable argument for it.
Object-oriented typing problem
When do we know whether the execution of an object-oriented system may produce a type violation?
In SmallTalk, the compiler does not check if every instance that declare “I’m a VisualComponent” does have an implementation of the method “paint()”. The developer can only verify the expected operation of the system by exercising the code in tests or production or by manually checking all classes.
Definition: statically typed language
An object-oriented language is statically typed if it is equipped with a set of consistency rules, enforceable by compilers, whose observance by a system text guarantees that no execution of the system can cause a type violation.
Doesn’t every organization crave for a look in the future? (Hint: If you are using a certain system called Oracle you know the answer 🙂 ). Using a statically typed language is basically a look into the future for free. You can see if your system is bound to fail at run-time. Giving that away doesn’t seem too smart.
Here are the characteristic properties when it comes to demixing your preferred language type-wise:
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?
Given that early detection of errors results in the lowest fixing costs it is desirable to know the answer to the question “when do we know we have a feature?” at “the earliest possible time”, determined by static type checking at compile time.
The answer to “what feature do we use?” should be “the right feature” – determined by dynamic binding at run-time.
Think of type checking a statically typed language text as an automated test you do not have to write because it is build into the system. I like that because it leaves more quality time to write tests that cannot be created by a machine :-)!
[Meyer97] Meyer, Bertrand: “Object-Oriented Software Construction, Second Edition”, Prentice Hall, 1997.