SQL3 OO Underlying Assumptions

1 INTRODUCTION

2 DEFINITION OF "OBJECT"

Proposed definition:

An object is an abstract concept which is represented in a system by an identifying reference (id-ref).

I have temporarily introduced the term "id-ref" to sidestep some corollary issues about oid's. It may well be that the final version of this definition will use the term "oid", if it is appropriately defined. My intent is that the term "id-ref" is broad enough to include, for example, identification of instances of ADT's which have no oid's.

3 SEMANTICS OF IDENTITY AND EQUALITY

It would be useful to (a) define the semantics of identity, and (b) clarify whether or not equality is intended to have such semantics.

The proposed semantics of identity are based on the notion of being the same object. I will use x==y to mean that x and y are identical, which should be true if and only if x and y refer to the same object. Certain behavioral characteristics should hold if x==y:

• x and y should be indistinguishable in their behavior. One should be replaceable by the other as the operand of any operation without altering the outcome. I.e., f(x) and f(y) should have the same effect for any f.
• x and y only refer to one object. Constructing the extensional set {x,y} should yield a set with one member, i.e.,

  {x,y}=={x}=={y}.

  This should hold in any context which does not admit duplicates.

Tuples which have different values in any component are clearly not identical. Also, if x and y refer to tuples of different lengths, then they clearly cannot satisfy either of these criteria (assuming that there is some operation which is sensitive to tuple lengths). Casting should not be confused with identity. If y can be substituted for x in f(x) by transforming y into something else, then y may be compatible with x in some sense, but they do not refer to the same object.

Two questions thus arise:

• Is this the intended semantics of identity?
• Is this the intended semantics of equality?

4 SEPARATION OF INTERFACE AND IMPLEMENTATION

Proposition: one of the fundamental goals of object orientation is to facilitate portability and reusability of applications. One means of achieving this goal is data independence, making applications as independent as possible of specific implementations. This allows applications to be reused with different implementations, and to be unaffected by changes in implementation. (They may have to be recompiled, but not reprogrammed.)

A corollary to this proposition is that schemas should be organized in a way that clearly distinguishes portions on which applications may depend (i.e., interface specifications) from portions to which they should be indifferent (implementation specifications). Schemas should also be organized so that one or more implementations can be specified for the same interface.

A simple example is given below. It is not in itself a concrete proposal, and it is not intended to display correct SQL syntactic form. It merely illustrates the concept. The example concerns circles for which the radius and diameter are both defined. Different implementations might store one or the other, or both.

CREATE TYPE Circle
FUNCTIONS (
Center -> Point ASSERTABLE;
Radius -> Number ASSERTABLE;
Diameter -> Number ASSERTABLE;)

CREATE CLASS Circle1 FOR Circle
FUNCTIONS (
Center AS STORED (format);)

CREATE CLASS Circle1a SUBCLASS OF Circle1
FUNCTIONS (
Radius AS STORED (format);
Diameter(x) AS 2*Radius(x),
ASSERTION x,y: Radius(x)<-y/2;)

CREATE CLASS Circle1b SUBCLASS OF Circle1
FUNCTIONS (
Radius(x) AS Diameter(x)/2,
ASSERTION x,y: Diameter(x)<-2*y;
Diameter AS STORED (format);)

Under this schema, all instances of the type Circle use the same implementation for Center, hence all circles are instances of the class Circle1. Instances of the subclass Circle1a have their radius stored and diameter computed, while instances of Circle1b have the opposite implementation. Every instance of the type Circle must also be an instance of one of the leaf classes Circle1a or Circle1b.

5 TYPE RELATIONSHIPS

SQL3 currently uses the term "subtype" to refer to two distinct relationships between types: inclusion and substitutability. It would be useful to at least clarify the two concepts, and to observe that both concepts are potentially applicable to all objects. This could lead to a proposal to use distinct terminology for the two.

The inclusion relationship, which I will denote t1 SUBSET t2, means that each instance of t1 is itself an instance of t2. Thus, for example, every memo is itself a document, and every employee is a person. This concept applies to non-oid objects as well as oid-objects. Thus the even integers are a subtype of the integers, and the tuple type <Employee,Integer> is a subtype of the tuple type <Person,Integer>. An instance <@sam,1000> of the former is itself an instance of the latter. (Syntax is illustrative only. @sam denotes an oid.)

Substitutability, which I will denote t1<t2, means that an instance of t1 may occur where an instance of t2 is expected. This relationship can be described in terms of a Cast operator

Cast: t1->t2.

If an operation f which is defined to expect an instance of t2 is invoked with an instance x1 of t1, the effect is that

f(x1) = f(Cast(x1)).

Inclusion can be viewed as the limiting case of substitutability, where the casting operation is the identity function Cast(x)=x, so that

t1 SUBSET t2 => t1<t2.

Substitutability is currently defined in SQL3 with respect to non-oid objects. However, it might be possible to define substitutability, and casting, for objects having oid's, in such cases as votes by alternate committee members, replacement of recipe ingredients, or stand-ins for performers.

That raises one concern. SQL3's current use of the term "subtype" to mean inclusion for oid-objects and substitutability for non-oid objects will make it difficult to deal with inclusion for non-oid objects and substitutability for oid objects.

Another concern arises regarding the context of substitutability. Substitutability may not apply to all contexts, and it might even involve different casting operators in different contexts. A long tuple may be substitutable for a shorter tuple in a context which only cares about the first few elements of the tuple, but it might not be substitutable in a context which cares about the length of the tuple.