Dynamic Types

William Kent
Database Technology Department
Hewlett-Packard Laboratories
Palo Alto, California

Nov 1993

SQL3 Discussion Paper
ANSI Number: X3H2-93-370r1
Nov. 15, 1993
Title: Dynamic Types
Author: William Kent

References:

1 X3H2-93-359R/ISO DBL MUN-003, (ISO-ANSI Working Draft) Database Language SQL (SQL3), Jim Melton (ed.), August 1993.

2 X3H2-93-309, "Constructors for ADTs", July 1, 1993, by Linda DeMichiel, Nelson Mattos.

3 X3H2-93-370, "Object Creation and Variable Management", July 30, 1993, by William Kent.

1 Status note

This paper replaces [3], which covered more topics in less depth. The present paper focuses on one of the topics introduced in [3].

2 Discussion

Object-oriented applications which model the behavior of real-world entities need the ability to add an existing object to a type, or to remove it from a type without destroying the object. Existing persons become employees, and later stop being employees while continuing to exist as persons.

This paper positions such dynamic typing as a language opportunity, outlining a plausible form it may take in the future. When consensus is reached on the details, it can be promoted to a language change proposal.

3 Action proposed

In Clause 3 ("Possible problems with the SQL3 language") of [1], in the section entitled "Language Opportunities", add the following Language Opportunity with a new number:

Dynamic typing.

Object-oriented applications which model the behavior of real-world entities need the ability to add an existing object to a type, or to remove it from a type without destroying the object. Existing persons become employees, and later stop being employees while continuing to exist as persons. This can be achieved with a modest extension of current facilities.

Under the existing facilities according to SR26 of Subclause 11.46, as introduced in the amendments adopted with [2], defining an ADT such as STUDENT causes the following routine declaration to be an implicit member of the ADT, serving as its constructor function:

PUBLIC FUNCTION STUDENT()
...
RETURN NEWSTUDENTI;

where NEWSTUDENTI is a new instance of STUDENT. It is also an instance of all supertypes of STUDENT.

As described in [2], data for the new object can then be initialized via user-defined routines which can be invoked in the form INIT_STUDENT(:x, initial-value-list), where the object to be initialized is the value of :x. It may even be possible to combine creation and initialization by invoking INIT_STUDENT(STUDENT(), initial-value-list).

A simple extension would be to allow a constructor such as STUDENT() to accept an optional parameter, whose value is an existing object which is to be made an instance of STUDENT. Suppose the value of :p is an instance of the ADT PERSON, defined as a supertype of STUDENT. Then STUDENT(:p) would make the existing person into a student. It would also become an instance of any intermediate types which may exist between STUDENT and PERSON. It could then be initialized by INIT_STUDENT(:p, initial-value-list). The initial-value-list would only have to initialize properties relevant to subtypes of PERSON; properties relevant to PERSON itself would not need initialization.

Removing an object from a type without destroying the object can be done in various syntactic forms. One approach is to allow a second optional parameter to the constructor, serving as a "removal" indicator.

The extended behavior of the constructor can be described informally by the following case statement for an ADT named ADTN (which takes parameters :x and :y):

The types of the variables :x and :y, as well as the returned result, remain to be worked out. Alternative syntactic forms can also be considered for explicit addition and removal of objects in types.