terminology confusion: subclass, superclass

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

This message is a bit long, but I thought it was a good idea to
gather all the discussion on the subject into one place.

    Date: Sun, 28 Dec 86 18:55 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    We need consistent terminology for distinguishing between the direct
    parents of a class and the transitive closure of parentage; similarly
    in the child direction.  Right now the document sometimes uses "superclass"
    and "subclass" to mean only the directly related classes, and uses
    "component" to mean "superclass^n, 0<=n" and "dependent" to mean
    "subclass^n, 0<=n".  In other places the document uses "superclass" to
    mean the transitive closure and "direct superclass" to mean the directly
    related classes, and similarly for "subclass" and "direct subclass".
    We need to be consistent about this.  I believe the component/dependent
    terminology is clearer, because it avoids using a single word to mean
    two things, but other opinions are welcome.

In one message of 29 Dec, RPG agreed with the components/dependents terminology
but in a later message he changed his mind.  I didn't save a reference to
the first message, hence this note.

    Date: 29 Dec 86 17:15 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I don't like the term component at all.  It suggests a part hierarchy,
    and for me any inheritance goes the wrong way; that is, components
    inherit features from their container not the other way.  For example, a
    car door, a component of a car, is the same color as the car (usually).

Well, one could just as well say that the color of the car is determined by
the color of its various parts, such as doors, fenders, etc.  However, the
point about the part hierarchy is well taken.

    Dependent is also a misleading word because of its usage wrt interface
    dependencies where a view of an object is a dependent on the state of
    the object itself.

    I suggest instead consistently use the term direct super(sub)class, or
    local super(sub)class versus the unmodified one to indicate the closure.

This is okay with me as long as it is consistent.  However, it seems evident
from the present state of the document that it's very easy to fall into the
trap of saying "superclass" when you mean "direct superclass", which can
confuse the reader.  It would help if we had a two-word phrase for the
transitive closure, so that any time the word "superclass" stands alone
we know it is ambiguous.  I don't have a suggestion, but perhaps someone
more mathematically inclined than I can suggest a term.

    Date: 29 Dec 86 18:33 PST
    From: Masinter.pa@Xerox.COM

    using subclass for transitive closure of direct subclass and superclass
    for transitive closure of direct superclass seems in my memory to be
    more prevalent at least in the Object Oriented Programming literature.
    That it uses a single word to mean two things is not so serious since
    there is a direct relationship (as opposed to just "a relationship")
    between the two things.  To use the mathematical analogy to its fullest,
    "A is a subclass of B" should be allowed when A = B, and "A is a proper
    subclass of B" be used to describe the situation where A /= B.

    Date: 29 Dec 86  2111 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    I believe we should distinguish immediate super/subclasses from
    the transitive closure of those relationships. I don't believe
    component/dependent are appropriate for the names of the transitive
    closures.

    For the moment I will call these relations superclass, subclass, superclass*,
    and subclass*. Also, I will use these words as nouns to refer to objects that
    bear the appropriate relationships to a given class.

I completely agree that the words for the relationships should also be used
as nouns referring to objects of the relationships.

    A component is a constituent part or ingredient. A superclass* might not be
    a constituent part of a class, because every aspect of it is shadowed.

    A dependent is something that relies on or is subject to something else.
    Again, a dependent might not depend on the superclass*, because everything
    is shadowed.

Why doesn't the same argument say that a superclass* isn't a "real"
superclass*, because it happens that nothing is really inherited from
it?  Furthermore, if a new method were added to the superclass*, for a
new generic function, then suddenly there would be something that was
inherited and wasn't fully shadowed, so the argument is very weak.  I
don't think this special case gives us any guidance on how to choose
terminology.

    ``Component'' and ``dependent'' are not related words, and many people
    who see the two together might not guess that one is the dual of the
    other.

This is a fair to good argument.

    I think that we should use the terminology:

    Term in this Message = New Term
            superclass*  = superclass
            superclass   = direct superclass
            subclass*    = subclass
            subclass     = direct subclass

    Date: 30 Dec 86 10:15 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I agree that it would be good to consistently use the terms in column New Term.

    Date: 30 Dec 86 10:55 PST
    From: Masinter.pa@Xerox.COM

    I agree with the New Term naming. I would like to add

            superclass+  = proper superclass
            subclass+   = proper subclass

Yes, this is important.

    Date: 30 Dec 86  1236 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Would you prefer to use the term ``proper superclass''
    or would you prefer to define that a class is not a superclass
    of itself?

    Date: 30 Dec 86 13:13 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I prefer to say that a class is not a superclass of itself.

It's very important to have names for "superclass^n, 0<=n" and
"subclass^n, 0<=n", the improper transitive closures.  That was the
motivation for my suggestion of "component" and "dependent", since
people often feel that "superclass" must mean the same as "proper
superclass".

    The only
    use of proper might come up in testing, where we use the terminology of
    types.  (SUBTYPEP 'object 'object) and (SUBTYPEP 'class 'object) are
    both true. 

Ah, since Common Lisp already defines that "subtype" is different from
"proper subtype", it makes sense for the object extension to Common Lisp
to define that "subclass" is different from "proper subclass" (and ditto
for "superclass").

               We need a function that will take two classes and return T if
    the first is equal to or a subclass of the second.  Should this be named
    SUBCLASSP?

Well, it certainly can't be named SUBCLASSP if "subclass" means the same
as "proper subclass", nor if "subclass" means the same as "direct subclass".
This is the same as my terminological argument about Lisp TYPEP meaning the
same as English "is a".  I'm not actually sure whether we need that function,
or can just use SUBTYPEP, but that's an independent issue.

My conclusion from all this is that we need consistent names for the six
concepts mentioned above, and I'm willing to drop the component / dependent
terminology in favor of completely consistent use of:
        xxx subclass            n>=0
        proper subclass         n>=1
        direct subclass         n=1
        direct superclass       n=1
        proper superclass       n>=1
        xxx superclass          n>=0
I'm looking for suggestions for the word xxx.  If we really can't think of
anything, that word could be omitted.