The notes are based on early experience using Trellis/Owl, a statically-typed object-oriented language developed at DEC. In this paper we equate "type" and "class" (in contrast to later work that we will examine).
In Smalltalk we say that a class obeys a certain message protocol. This is informal and descriptive in Smalltalk, but is formalized in Trellis/Owl's type system.
The object-oriented paradigm encourages programmers to concentrate on the objects being manipulated rather than the code that does the manipulation. Example: in Scheme there is a single "write" procedure that must work on all kinds of data. In Smalltalk each kind of object understands the "printOn:" message. It is sometimes appropriate to make objects that represent processes, as well as program objects representing objects in the system being modelled. Example: should we make airplane objects that understand a "fly" message? Or should we make flights into objects?
Another example: lexical scanner. Should we implement the scanner as an operation on Strings, or make a separate Scanner object?
Aphorism: use objects to model entities in the application domain -- however, generally we will also need to introduce other objects that help us code the application.
Uses of subtyping:
inspect message -- but the details of
the inspector window etc are all in an inspector object. There are also
specialized inspectors for dictionary, MVC triads, etc.