Database Technology Department
Palo Alto, California
SQL3 Discussion Paper
ANSI Number: X3H2-93-370r1
Nov. 15, 1993
Title: Dynamic Types
Author: William Kent
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.
This paper replaces , which covered more topics in less depth. The present paper focuses on one of the topics introduced in .
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.
In Clause 3 ("Possible problems with the SQL3 language") of , in the section entitled "Language Opportunities", add the following Language Opportunity with a new number:
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 , 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()
where NEWSTUDENTI is a new instance of STUDENT. It is also an instance of all supertypes of STUDENT.
As described in , 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):
If :x is omitted, then behave as currently specified, i.e., create a new object as an instance of ADTN and all supertypes of ADTN, and return that object.
If :y is omitted,
If :x is already an instance of ADTN, then just return :x.
Make :x an instance of ADTN and all supertypes of ADTN of which :x is not already an instance, and return :x.
If :x is not an instance of ADTN, then just return :x.
Remove :x as an instance of ADTN and all subtypes of ADTN.
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.