Object-oriented programming languages are currently advocated by many as the long awaited solution to the software crises. For the most part, the author agrees that these high expectations are justified. However, it should not be imagined that these languages have advanced programming language expressivity to the natural limits.
For example, consider an object-oriented design for a university database. It seems likely that the designer will have introduced a class Person with sub classes Student and Staff-member. The usual interpretation of classes as types require Student and Staff-member to be disjoint. In real life, however, these sets are not disjoint and the designer thus will have to go further.
In simple cases, multiple inheritance seems the answer. If the designer adds a Student-staff-member class, which inherits from both Student and Staff-member, to the database schema the problem seems solved: An instance of Student-staff-member ISA Student and ISA Staff-member, the latter two classes are thus no longer disjoint.
Consider, however, the complications that arise when using this technique to model the real life intersections between classes Student, Staff-member, Parent and Sports-club-member. Must the database designer anticipate the need for the class Sporting-parent-student-staff-member? Surely not!
Consider further, the complications that arise if the designer decides to introduce sub classes Academic-staff-member, Administrative-staff-member, Technical-staff-member, and so on. In this case, creating an instance of Student-staff-member creates a staff member object that belongs to none of the sub classes of Staff-member. The designer thus is forced to remove class Student-staff-member from the schema and replace it with Student-academic-staff-member, Student-administrative-staff-member, and so on.
The author suspects that the database designer will simply give up and provide a schema that is an oversimplification of the real world. The application programmer ends up having to solve the problem, typically by adding explicit run-time type checks all over his code.
If the designer can use dynamic types that can intersect in arbitrary ways, the above modeling problems simply do not arise.
Prof Herman Venter