References:

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

1 DISCUSSION

1.1 Inheritance of components

This proposal clarifies the conditions under which new specific routines are created in subtypes.

If we define the type Person with an Address function, and then define a subtype Student under Person with another Address function, then there will be two distinct specific functions, which we will denote by the specific names PAddress and SAddress. The existence of distinct specific functions is evident if we assume that either now or in the future it is possible to cause these functions to be explicitly invoked and independently updated, so that PAddress(x) and SAddress(x) might have different non-null values for the same value of x. Due to the late binding semantics of subject routine determination, PAddress(x) might be different from Address(x) if x is a student, since Address(x) will then be interpreted as SAddress(x).

Suppose now that Teacher is also defined as a subtype of Person, without an explicit Address function. It would seem that the user's intent is that the address of a teacher is the address of the person who is the teacher, in the same sense that the birthdate of the teacher is the birthdate of the person who is the teacher. Under this interpretation, the user deliberately avoided re-specifying the Address function because the user did not want a different specific function to be created.

1.2 Rule concerning inheritance of components

1.3 Redefinition of components in inheritance

1.4 Inheritance of routines

1.5 Substitutability does not imply subtype

Subtypes imply substitutability, as stated in Subclause 4.10: "If Ta is a subtype of Tb, then an instance of Ta can be used wherever an instance of Tb is expected. In particular, an instance of Ta can be assigned to a variable of type Tb, passed as an argument for an input parameter declared as type Tb, and returned from a function whose result type is declared to be Tb."

1.6 Component inclusion does not imply subtype

1.7 Limitations of substitutability

2 CHANGE PROPOSALS

2.1 Inheritance of components

In Subclause 4.11.2 (Subtypes and Supertypes for ADTs):

In the fourth paragraph, replace the sentence

"Effectively, components of all direct supertype representations are copied to the subtype's representation with same name and data type."

with the sentence

"Effectively, components of all direct supertype representations are reused in the subtype's representation, unless replaced by explicit specification of a component with the same name."

2.2 Rule concerning inheritance of components

In Subclause 11.46 (<abstract data type body>):

At the end of SR 11 Case b) "Otherwise, an implicit <member list>...", add the sentence

Components of the inherited representation of STD are not originally-defined components in TUP.

2.3 Redefinition of components in inheritance

In Subclause 11.46 (<abstract data type body>):

Before SR 12 ("Let same component mean..."), add the following new SR appropriately numbered as x:

x) Each component in the inherited representation of STD which has the same name as a component in the explicit <member list> of STD is dropped from TUP.

2.4 Inheritance of routines

In Subclause 11.46 (<abstract data type body>):

In SR 5 ("If <member list> is specified, then"),

• add "or <routine declaration>s" after the one occurrence of "<attribute definition>s", and
• add "or <routine declaration>" after each of the two occurrences of "<attribute definition>".

2.5 Substitutability does not imply subtype

In Subclause 4.10 (Subtypes and supertypes):

Add the following paragraph at the end:

Although subtypes imply substitutability, the converse does not hold. There is a form of substitutability based on casting which does not imply subtypes. Let f be an operation with argument type Tb. If there is a casting function from Ta to Tb, then f(x) will execute successfully if x is an instance of Ta. This is substitutability, since an instance of Ta can be used where an instance of Tb is expected, but this does not make Ta a subtype of Tb.

2.6 Component inclusion does not imply subtype

In Subclause 4.10 (Subtypes and supertypes):

Add the following paragraph at the end:

Subtypes imply component inclusion, in the sense that if the type PERSON has an Address component then the subtype STUDENT has an Address component. The converse does not follow: component inclusion does not in itself imply subtyping. The type PERSON may be defined with components Name, Age, and Address, and the type WINE may be defined with components Name and Age, but that does not suffice to make PERSON a subtype of WINE.

2.7 Limitations of substitutability

In Subclause 4.10 (Subtypes and supertypes):

Add the following paragraph at the end:

Substitutability may not extend to the target of an update. Suppose Move(p,d) is an operation which moves a person p to an address d, i.e., changes the address of the person. It does not necessarily follow that any person can be moved to any address. Suppose students are required to reside in the United States. If p is an instance of Person, then Move(p,London) would be valid - but not if p is an instance of Student. Thus this instance of Student could not be substituted where an instance of Person is allowed.