Polymorphism, persistence and software re-use in a strongly typed object-oriented environment

Abstract

The major requirements of a system for software reuse are that it must provide an abstraction mechanism for adequately describing the components; a mechanism for naming and storing the components; and a mechanism for composing new objects out of existing components.In this paper we describe a polymorphic type system that may be used to describe generic components and a persistence mechanism that may be used to name, store and compose components. By integrating the two, we obtain a strongly typed persistent environment that is an ideal base as a system for software reuse.

The Napier88 Persistent Programming Language and Environment

“…For modelling purposes it is generally agreed that some form of polymorphism is required to capture the expressiveness of data models and to increase component re-use [18]. The most favoured forms of polymorphism are universal polymorphism: parametric or inclusion.…”

“…The system was also intended as, or turned out to be, a testbed for experiments in: type systems for data modelling [2][3][4][5][6][7], bulk data [8,9] and protection [10,11]; programming language implementation [12,13]; binding mechanisms [14][15][16][17]; programming environments [17][18][19][20]; system evolution [21][22][23]; concurrency control and transactions [24][25][26][27]; object stores [26,[28][29][30][31][32][33][34][35] and software engineering tools [36][37][38][39].…”

Exploiting Persistent Linkage in Software Engineering Environments

“…In each of these systems persistence is used to abstract over the physical properties of data such as where it is kept, how long it is kept and in what form it is kept, thereby simplifying the task of programming. The benefits of orthogonal persistence have been described extensively in the literature (Atkinson, Chisholm et al, 1982;Atkinson, Bailey et al, 1984;Atkinson and Morrison, 1985;Atkinson, Morrison et al, 1986;Atkinson and Buneman, 1987;Dearle, 1987;Morrison, Brown et al, 1987;Wai, 1987;Dearle, 1988;Brown, 1989;Connor, 1990;Cooper, 1990a;Cooper, 1990b;. These can be summarised as:…”

“…Typical examples of such systems are CAD/CAM systems, office automation, CASE tools and software engineering environments (Morrison, Bailey et al, 1985;Morrison, Brown et al, 1987). Others include Object-Oriented Database Systems such as GemStone (Bretl, Otis et al, 1989) and O 2 (Bancilhon, Barbedette et al, 1988), which have at their core a persistent object store, and process modelling systems, which use a persistent base to preserve their modelling activities over execution sessions (Bruynooghe, Parker et al, 1991;Curtis, Kellner et al, 1992;Han and Welsh, 1993).…”

Changing Persistent Applications

“…In a persistent programming language which supports first class procedures 1 , such as Napier88 [10], the objects in the store include procedures with bindings to data, and data with bindings to procedures. Persistent systems support incremental construction [4] and component reuse [9] by allowing components to be created, stored in the persistent object store and bindings between them established. Bindings may be established at different times: during program construction, at program compile time and when the program is executing [7].…”