[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: accessor functions
- To: cl-object-oriented-programming%SU-AI@SRI-KL
- Subject: Re: accessor functions
- From: Dan Carnese <Carnese@SRI-KL>
- Date: Thu 24 Jul 86 16:45:33-PDT
- In-reply-to: Message from "David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>" of Thu 24 Jul 86 13:01:48-PDT
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
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.