Re: accessor functions

[Dan Carnese <Carnese@SRI-KL>]

    Date: Thu, 24 Jul 86 14:50 EDT
    From: David A. Moon

    I and most (but not all!) of my users agree with this philosophy
    and use it also.

        Date: 23 Jul 86 13:27 PDT
        From: Gregor Kiczales <Gregor.pa@Xerox.COM>

        It is true that the default value for the "conc-name" is the name of the
        class.  But in practice I tend to use the same conc-name for all the
        classes in a class-tree.  As an example, in PCL the conc-name for
        essential-class and all the classes which include it is "class-".  This
        means that the accessor for the slots of any kind of class is
        "CLASS-SLOTS".  When I see "(class-slots x)" in code, I read it as "x is
        some kind of class, there will be a method on class-slots which knows
        how to get x's slots.

        While generic functions let you use a conc-name of nil I personally
        don't like this style.  As an example, using conc-name nil would allow
        the accessor for all things which have a name to be just "NAME".  I
        prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
        of class.

        Perhaps a more liberal use of packages or just the passage of time will
        change my philosophy about this, I don't know.  

Well, the obvious problem with this convention is that you have to change a
potentially large number of function names if you ever decide to rename a
class.  This was in fact a major drawback to the old Clu requirement that
all operations include the name of the type (e.g., class$frob).  Alan will
appreciate the irony that in some circles this is now considered
appropriate Lisp style.

Seriously, though, there is a good argument that the semantics of type
operations should be tied to each other, not to a particular symbol naming
the type.  E.g., the push and pop functions should be defined in terms of a
(push pop) complex, not a random name like "stack".  Of course, there's no
problem with using the variable "stack" to refer to this complex, in just
the same way that the variable "zero" can be used to refer to the object 0.

Most contemporary work in type theory and type inference conceptualizes
types as collections of operations.  Intelligent type checking involves the
computation of the minimal set of operations required for each parameter of
each function to guarantee that no possible invocation can cause a "missing
alternative for generic function" error.  Such sets are in general a
subset of the complete operation set of a type.

-- Dan
-------