Re: accessor functions

[Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>]

(I know this was addressed to Moon and Gregor, but I'll answer anyway
whilst I look forward to seeing their answers.  Let me emphasize again
that I don't speak for Moon on this issue.)

    Date: Thu, 24 Jul 86  12:25:12 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Indeed, this does seem somewhat redundant with the package system.
    Do you (and your users) also typically define a separate package for
    an entire "class-tree"?  If so, why not use CLASS:NAME instead of
    CLASS-NAME?

Well, actually, even apart from object oriented programming, one always
has to make the choice between putting things in their own package, or
using a prefix, or whatever.  I don't think we've been using New Flavors
long enough that a very clear dominant style preference has emerged.

I recently converted our error/condition system to use generic functions
wherever it used to use messages.  It happens that there's already a
package called DEBUGGER, or DBG for short, that doesn't have much in it
besides the error/condition stuff and the interactive debugger.  So
several of the generic function names are simply things like DBG:REPORT,
DBG:PROCEED-TYPES, etc.  On the other hand, we also used the names
DBG:CONDITION-STATUS and DBG:CONDITION-TYPE, which we felt were clearer.

In any case, I think this is the same issue that arises with non-generic
function naming, and doesn't have anything to do with genericness (with
object-oriented programming) per se.

    Also, do you use the CLASS- prefix for ALL operations defined
    on a CLASS, or just the instance variable accessor functions?
    I notice in the SHIP example in the December 85 New Flavors paper that
    the function SHIP-MASS is defined to read the MASS instance variable,
    but the function SPEED (rather than SHIP-SPEED) is defined to
    compute the speed.  Is MASS less generic than SPEED?

I don't know about the particular example, but in general there is no
reason to treat an instance variable accessor function any differently
than any other generic function.  They could have been written by hand,
if defflavor didn't provide a handy-dandy convenience feature to write
them for you.  Most important, the caller does not and should not know
whether any generic function is or is not an instance variable accessor
function; that's the business of the implementation, and not visible in
the protocol specification.