in order to allow the efficient handling of such kinds of data. The RDBMSs do not support such handling and therefore the object-oriented technology had to enhance the classical transaction framework with long and nested transactions. Most of the applications evolve and they do no acquire a stable state until a long time after their initial implementation. For this reason it should be possible to do the following: the old data should not be overridden by new ones but should be kept and coexist as older versions of the same object and not as independent objects; and in case of schema changes, the data that corre!spond to previous schemas should not be thrown away but should evolve following the schema evolution.There is a set of features, finally, for which the designers can choose among different implementations that are not equivalent, but they have certain advantages and disadvantages. There are plenty of programming models (C++, Lisp, Smalltalk, etc.), but none of them should be considered better than the others. The designers choose the programming model of their system according to the kind of applications that the system is going to serve. The choice of the programming style is open as well. The one that better suits the applications should be chosen. The representation system is the set of the types or classes provided by the system as well as the set of constructors that can be applied on these classes. As long as the system provides support for extensibility and composite objects, there is no restriction of which member the representation should contain. There are systems that support the highest degree of uniformity, which means that everything in the system includ!ing classes, methods, messages, etc. is treated as an object. Uniformity has consequences at the level of the implementation of the system and at the level of the application programming and the user interface as well. Although uniformity is a nice fea...
