Types and Classes: Prescribed Vocabulary

1 INTRODUCTION

This is a sneak preview of some incomplete work in progress, to give you an idea of where it's heading and give you a chance to propose early course corrections. It's a trial balloon in various matters of style and organization, which are all negotiable.

There are two important concerns. The first is to be sure we've identified the appropriate set of concepts, and defined them in a satisfactory way. The second is to settle on the specific terms we will use for these concepts. The first is really the most important, since our shared understanding of the topic rests on common understanding of the concepts. The second point, choosing specific terms, will probably be quite contentious in some cases, but it's largely just a matter of haggling. Everybody has to be prepared to compromise some favorite item of terminology; we simply don't all share a common vocabulary. That's why we're in business in the first place.

I've done more than simply extract from the existing entries in the glossary and features matrix. I've also tried to address ambiguities and issues that in some cases haven't been exposed in the existing entries. Flushing out these ambiguities and issues, and addressing them in our prescribed vocabulary and in our analyses, comprise an important part of our work.

We don't need prescribed definitions for all the terms in the glossary. We only need to have agreed terminology for the concepts that matter to us. The other terms can be included as a record of their usage, but we aren't obliged to prescribe for all of them.

Terms are presented in expository groupings rather than alphabetically. References to existing glossary entries are written as [G"abc"(1)], meaning definition 1 under the glossary entry for "abc". References to entries in the features matrix are of the form [F3.1p5], meaning section 3.1 on page 5. I have enclosed all occurrences of formally defined terms in angle brackets, as in <type>. Where the term is being defined, I have enclosed it in double brackets, as in <<type>>. The result does look somewhat cluttered, and we may want to reconsider this convention.

Definitions are accompanied by observations and variants. Observations are just general comments and clarification. Variants call attention to things we have deliberately not specified in the definition because they are legitimate variants within the basic concept. These variants can guide the analysis of the features matrix, asking how each model treats these variants of the concept.

Examples to be used (Student is a subtype of Person):

Name: Person p -> String n.
Birthplace: Person p -> City c.
Residence: Person p -> City c.
Children: Person p -> SET(Person c) s.

Oldest: SET(Person p) s -> Person p.

Residence: Student s -> City c.
Major: Student s -> Subject s.
Gpa: Student s -> Integer g.
Courses: Student x ->SET(Course c) y.

Register: Course c, Student s -> Void.
Grade: Student s, Course c -> Integer g.
President: Class c -> Student s.

@sam, @pam, etc. are constants whose values are objects. This is an informal expository notation.
@pam is a person, @sam is a student, hence also a person.

2 PRIMARY DEFINITIONS

2.1 Type

Definition: A <<type>> is a grouping of <objects> which can play the same <roles> in the same <specific operations>. A <type> has one or more <extensions>, one or more <type interfaces>, and a <typing predicate>.

Observations:

• A <type> provides a linkage between <objects> and <operations>, serving as an indirect means of specifying which <objects> can participate in which <operations>.

  For example, instead of saying that @sam can occur as the second argument in a Register request, and as the first argument of a Grade request, and as the result of a President request, and then saying these things again many times over for many individual objects, we make these assertions once for the type Student, with the understanding that it holds for any instance of the type. Making something an instance of the type means that all these assertions apply to it.

• This definition doesn't match any current glossary entry. It's intended to be more precise than any of those.

Variants:

• A <type> may or may not be named. [Need to discuss type identity, signature-based types (a different meaning of "signature"?).]
• A <type> may be the same thing as one of the associated constructs, i.e., the <type> itself might also be an <extension> or a <type interface> or a <predicate>.
• A <type> may be an <object>, which may sometimes be further refined to <meta-object>.

2.2 Typing Predicates

Definition: The <<typing predicate>> associated with a <type> is a <predicate> whose value is <True> if and only if it is <applied> to an <instance> of the <type>.

Observations:

2.3 Instances

Definition: <<Instance>> is a <relationship> between an <object> and a <type>, such that an <object> is an <<instance>> of a <type> if and only if the <object> is a <member> of the <extension> of the <type>.

Definition: An <object> is a <<direct instance>> of a <type>, and the <type> is a <<direct type>> of the <object>, if and only if the <object> is not an <instance> of any <proper subtype> of the <type>.

Observations:

• The unqualified terms <type> and <instance> do NOT mean <direct type> or <direct instance>.
• There are several mechanisms by which an <object> can be established as an <instance> of a <type>:
  • By assertion, e.g., by simply creating an <object> as an <instance> of Employee. This implies that <operations> defined on Employee are automatically made applicable to the <object>.
  • By testing whether the <object> meets criteria for being an <instance> of the <type>. The most common form of test is to determine whether the <operations> defined on the <type> can be applied to the <object>. Any <object> which satisfies the test is an <instance> of the <type>.
  • In addition, the implications of <inclusion subtyping> apply, whereby an <object> which becomes an <instance> of a <subtype> becomes an <instance> of its <supertypes>.
• Don't confuse <direct instance> with the <type> in which the <object> was originally created. If an <object> is created as a person and then becomes an employee, it becomes a <direct instance> of Employee and is no longer a <direct instance> of Person. Conversely, if originally created as an employee and then fired, the <object> becomes a <direct instance> of Person.
• Glossary note: "immediate" is often used in place of "direct".

Definition: <<Multiple typing>> occurs when an <object> has more than one <direct type>.

Definition: <<Dynamic typing>> occurs when an <object> may become an <instance> of a <type> at some time after the <object> is created, and may stop being an <instance> of a <type> at some time before the <object> is deleted.

Variants:

• <Multiple typing> might not be supported.
• <Dynamic typing> might not be supported.
• Some models differentiate between <types> which can be acquired and lost dynamically and whose which are intrinsic to an <object> throughout its lifetime. Some models use the term "type" to mean the intrinsic kind and "class" to mean the dynamic kind. [Do some models do the opposite?] Some models use the term "role" for the dynamic kind of type, which differs from the definition of "role" used herein, though there is some connection between the concepts.

2.4 Extensions

Definition: An <<extension>> of a <type> is a set of <instances> of the type.

Observations:

• Some <extensions> may be enumerable, others may not be.
• SQL3 allows multiple <extensions> associated with a <type>, e.g., within different tables.

Variants:

• <Extensions> may or may not be supported for some or all <types>.
• The term "type" corresponds to an <interface>, while the term "class" is used to mean <extension>.

Definition: A <<complete extension>> of a <type> is the set of all <instances> of the <type>.

Observations:

• The notion of "all <instances>" should be defined relative to some scope.
• SQL3 does not currently support the notion of a <complete extension>, except in the incidental sense where only one <extension> happens to be defined for the <type>.
• The unqualified term <extension> means <complete extension> in this paper.
• Glossary note: "extent" is often used in place of "extension".

Variants:

• <Complete extensions> may or may not be supported for some or all <types>.

Definition: A <<direct extension>> of a <type> is a set of <direct instances> of the <type>.

Observations:

• The unqualified term <extension> does NOT mean <direct extension> in this paper.

2.5 Interfaces

Definition: A <<type interface>> of a <type> is a set of <specific operations> in whose signatures the <type> is the <controlling parameter type> or a <subtype> of the <controlling parameter type>.

Observations:

• Caveats:
  • We didn't say all such operations.
  • We said <specific operations>, not operation names or <generic operations>. An implication of this is that the <specific operations> Person#Residence and Student#Residence may both occur in a <type interface> for Student. If we want the <type interface> to only contain Residence once, then we have to recast the definition of <type interface> in terms of <generic operations> or <operation> names.
  • We said <controlling parameter>, not any <parameter>.
• We use the qualified term "type interface" in anticipation of the fact that a different notion of "interface" will be defined for individual objects.
• A <type interface> don't completely describe the uses of a <type>. The <type interface> only reflects participation as <controlling parameter>, not as other <parameters> or <results>.
• There are many variations on this notion of <type interface>. Definitions follow. We will use operation names in the examples, avoiding the issue of generic vs. specific operations.

Definition: The <<complete x type interface>> of a <type> is the union of all < x type interfaces> of the <type>, where x might be "direct" or "effective".

Definition: A <<direct type interface>> of a <type> is a set of <specific operations> in whose <signatures> the <type> is a <controlling parameter>.

One <direct type interface> of Student might be {Major, Grade}.

Definition: The <<complete direct type interface>> of a <type> is the union of all <direct type interfaces> of the <type>.

The <complete direct type interface> of Student is {Residence, Major, Gpa, Courses, Grade}.

Definition: An <<effective type interface>> of a <type> is a combination of a <direct interface> of the <type> and <effective interfaces> of <supertypes> of the <type>. How such combining is done gets into the subject of <inheritance>, which we defer.

One <effective type interface> of Student might be {Major, Grade, Name, Birthplace}.

Definition: The <complete effective type interface> of a <type> is the union [or possibly some other combination?] of all <effective type interfaces> of that <type>.

The <complete effective type interface> of Student is {Residence, Major, Gpa, Courses, Grade, Name, Birthplace, Children}.

Variants:

• [Say something about the different sorts of type interfaces being supported in different models.]
• <Interfaces> may or may not be named, and they may or may not be distinct <objects>.
• There's another important issue which needs to be discussed under the topic of <inheritance>. When Name is "inherited" by Student from Person, does this mean that one and the same Name <operation> occurs in both places, or that a new <specific operation> also called "Name" is automatically created? The semantic issue is whether or not there are distinct <specific operations> Person#Name and Student#Name which could have different values for the same <argument>. Different models take different positions on this question.

2.6 Subtypes

Definition: <<Subtype>> and <<supertype>> are inverse relationships among <types>. If T2 is a <<subtype>> of T1 (and hence T1 is a <<supertype>> of T2), then an <instance> of T2 may occur wherever an <instance> of T1 may occur, i.e., [an <instance> of] T2 is <<substitutable>> for [an <instance> of] T1.

Observations:

• This is not <proper subtype>. A <type> is a <subtype> of itself.
• <Substitutability> may not hold for update, i.e., for an assignment such as Residence(@sam)<-London. If there is a restriction such that students must reside in the United States, then an instance of Student may not occur in this assignment expression even though other instances of Person can. Such a restriction might arise either from a constraint which asserts that a person who is a student must reside in a city in the United States, or from a redefinition (overloading) of the Residence function of the form Residence: Student s -> USCity c.

Definition: A <<proper subtype>> [or <<proper supertype>>] of a <type> is any <subtype> [or <supertype>] of the <type> other than the <type> itself.

Definition: If T2 is an <<inclusion subtype>> of T1 (and hence T1 is an <<inclusion supertype>> of T2), then an <instance> of T2 is an <instance> of T1, i.e., the <extension> of T2 is a <subset> of the <extension> of T1.

Observations:

• <Inclusion subtype> and <inclusion supertype> are stronger than (imply) <subtype> and <supertype>, but not conversely. [Illustrate.]
• We need to proceed carefully here. I believe that the distinction only holds if we talk about <generic operations> or <operation> names in <type interfaces>. If we talk about <specific operations>, I believe the distinction might disappear.

Definition: T2 is a <<direct subtype>> of T1, and T1 is a <<direct supertype>> of T2, if T2 is a <proper subtype> of T1 but not a <proper subtype> of any <proper subtype> of T1.

Observation:

• The unqualified terms <subtype> and <supertype> are sometimes misread as <direct subtype> and <direct supertype>. This is NOT intended here.

[Again 2 modes, like instances: assertion vs. test, by interface inclusion. Not instance inclusion; not same as subset.]

Variants:

• Some models (e.g., SQL3) require a unique "maximal" or "base" <supertype>, such that a <type> can have at most one <supertype> which does not itself have a <proper supertype>.
• Some models support a <type> whose <intstances> include all <objects>, which then automatically is the maximal <supertype> for all <types>.

2.7 Classes

[To be completed. Notes...]

Definition: A <<class>> defines an implementation of a type.

The following 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.

3 OTHER VARIANTS

Old material. Needs to be revised.

1. Types are defined by the system (built in), while classes are defined by users.
2. A type is determined by its interface. If t1 and t2 have the same interface, they are one and the same type. Changing an interface creates a new type.
3. Alternatively, a type has identity independent of its interface.

4 AUXILIARY DEFINITIONS AND NOTES

Definition: An <<object>> is anything which has a <type>, i.e., anything which can occur as an <argument> or <result> of a <request>.

Observations:

• An <object> might be a <literal> or <aggregate>, etc., which is not made clear in any of the definitions in [G"object"], though it is the intent of OODBTG. Alternatively, we would have to develop a parallel set of definitions for object types and non-object types, as in the OMG Core Model.

Definition: An <<operation>> is something which can be referenced in a <request> along with zero or more <argument> <objects>. Same as [G"operation"(1)]. An <operation> may be a <specific operation> or a <generic operation>. Some models only allow a <generic operation> to be referenced in a <request> (i.e., by unqualified name only).

The unqualified term <operation> means <specific operation> in this paper.

Definition: A <<parameter>> is a specification within the <signature> of an <operation>. Commonly also known as a "formal parameter", though the definition in [G"formal parameter"(2)] doesn't seem clear.

Definition: An <<argument>> is a value provided in a <request>, similar to [G"argument"(2)] and [G"actual parameter"(2)].

Definition: A <<specific operation>> is defined with a <signature> and a <behavior specification>.

Variants:

• Some models provide syntax allowing the user to distinguish between different <specific operations>, allowing such operations as Person#Residence(@sam)<-London. With this facility, Person#Residence(@sam) and Student#Residence(@sam) could have distinct values.

Definition: A <<signature>> consists of one [zero] or more <parameter> <types> and a <result> <type>. (Alternative: there is [at most] one <parameter> <type>, with multiple parameters modeled as a tuple [list?] type.) A <role label> may be associated with each <type> in a <signature>.

Observations:

• A <signature> of the form f: T1->T2 only guarantees that f(x) will return an instance of T2 if x is an instance of T1. It does not guarantee that any instance of T2 could be the value of f(x) if x is an instance of T1. (Note earlier discussion of substitutability.)

Not discussed: in/out parameters.

Various possible name uniqueness constraints (within some scope): <specific operations> with the same name can't have the same

• <Signature>.
• Parameter portion of the <signature>.
• <Controlling parameter>.

Definition: A <<controlling parameter>> is one of the <roles> in a <signature>. In a <classical> (messaging) model, it corresponds to the message target.

Observations:

• In this paper, the <controlling parameter> is assumed to be the first <role> in a <signature>. Thus x is the <controlling parameter> in f(x,y). The messaging form x.f(y) is a common syntactic alternative.

Definition: A <<generic operation>> exists for each set of <specific operations> having the same name.

Observations:

• A <generic operation> occurring in a request must be <resolved> (bound?) to a <specific operation> before execution of the request can be completed.
• There is a one-to-one correspondence between <generic operations> and <operation> names.

Definition: A <<role>> is a position within the <parameter> or <result> of a <request>, and corresponds to an occurrence of a <type> in the <signature> of the <specific operation> associated with the <request>.

Definition: A <<role label>> is a <variable> (<parameter>) associated with a <role> in a <signature>. <Role labels> are unique within a <signature>.

Example. [Start with a simpler example].

<Aggregate> (composite, parameterized, generated) types give rise to nested roles. In

Oldest: SET(Person p1) s ->Person p2,

there are three roles. The role s corresponds to the first parameter of Oldest, and may be played by any set of persons. The role p2 corresponds to any member of a set playing the role s, and may be played by any person. The role p2 corresponds to the result of Oldest, and may be played by any person.

Correlate "playing a role" with binding a parameter to an argument.

Note: when we talk about requests and messages, we should differentiate between references to <generic operations> and <specific operations>.

Definition: A <<predicate>> is a <boolean>-valued <operation> which can be applied to any <object> (or <list> of <objects>).

Definition: <<Member>> is a relationship between an <object> and a <set> (or other <aggregate>).

Observations:

• The convention is that <types> have <instances> while <sets> have <members>.

5 ALPHABETICAL SUMMARY OF RELEVANT TERMS

[To be completed.]

6 NOTES

Check all relevant terms and concepts in glossary and features matrix, including supplementary papers. Use or relate to existing definitions where possible.

If <signature> or <role> need to have other meanings as well, then the terms defined herein could be qualified as <operation signature> and <operation role>.

7 ADDENDUM ON GROUPS

Having looked at a couple more models recently (not currently in the Features Matrix), I observe a further diversification of concepts.

With the two terms "type" and "class" we seem to be trying to define two grouping concepts. However, there seem to be at least three grouping concepts based on different criteria for the grouping. On the other hand, there are about four constructs which can be associated with each grouping concept, yielding perhaps a dozen distinct notions. Probably no model has all twelve, but it would be nice if any model could be described in terms of some subset of these. Actually, it's not so much a subset as a merging: something in a given model may represent some combination of such notions. We should be able to characterize different models by the way they package these building blocks.

The grouping concepts differentiated by grouping criteria:

• Grouping things having similar behavior/interfaces. Let's say these groups are types.
• Grouping things which exist in a certain "scope". Let's say these groups are rosters.

  (I've adopted that term for this purpose, but it's negotiable. We might also use the term "extent", provided we don't also want to refer to the extent of any group.)

• Grouping things having the same form of implementation. Let's say these groups are classes.

There may be other criteria as well, but these seem to be all the ones associated with the terms "type" and "class" in object models. The term "class" is variously used for each of these concepts in various models.

Constructs associated with any grouping concept:

• The grouping concept itself (e.g., a type or class object).
• Sets of things "belonging" to the group.
• Predicates which test whether a thing belongs to the group.
• Associated interfaces, i.e., operations which can be applied to things belonging to the group.
• Data structures [this is shaky; elaborate?].

Types, rosters, and classes are often interrelated in various ways. Some plausible configurations:

• They are all the same. The model has a single construct which serves all these purposes. A type has one associated set of instances, all having the same implementation.

Types are used to define interfaces, but instances belong to rosters rather than types.