Types and Classes: Prescribed Vocabulary

Jan 1994
Title: Types and Classes: Prescribed Vocabulary
Author: William Kent
Status: Working draft (Version 1)

> 1 INTRODUCTION . . . 2
>> 2.1 Type . . . 3
>> 2.2 Typing Predicates . . . 3
>> 2.3 Instances . . . 4
>> 2.4 Extensions . . . 6
>> 2.5 Interfaces . . . 7
>> 2.6 Subtypes . . . 8
>> 2.7 Classes . . . 9
> 3 OTHER VARIANTS . . . 10
> 6 NOTES . . . 13


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.

I will use the notation Person#Residence and Student#Residence to distinguish different specific operations having the same name.


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



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



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


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.


2.4 Extensions

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



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



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


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


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}.


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.


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.


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.


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


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.

Center -> Point ASSERTABLE;
Radius -> Number ASSERTABLE;
Diameter -> Number ASSERTABLE;)

Center AS STORED (format);)

Radius AS STORED (format);
Diameter(x) AS 2*Radius(x),
ASSERTION x,y: Radius(x)<-y/2;)

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.

Application logic is sensitive only to the specification of the type Circle, and not to the specification of any of the classes. The keyword ASSERTABLE tells the application that new values may be assigned, while remaining neutral as to whether and how the values are stored.


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.


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


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


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


Not discussed: in/out parameters.

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

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


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


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>).



[To be completed.]

[Make sure all new terms introduced above are captured here.]


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

For any qualified term of the form <p q>, it's usually useful to have an entry for <q> which points to <p q>.


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:

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:

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

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