Re: accessor functions

[Alan Snyder <snyder%hplsny@hplabs.HP.COM>]

    Date: Fri, 25 Jul 86 12:10 EDT
    From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>

        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.

Even better would be DBG:CONDITION:STATUS and DBG:CONDITION:TYPE I would
think (if such a thing were legal).

    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.

There are many cases where the introduction of object-oriented programming
tends to focus attention of existing problems in Common Lisp.  The package
system is probably the worst offender.  However, if you are implying that
because these problems are already in Common Lisp we should not worry about
them now, I disagree.  The interactions with object-oriented programming make
it especially important that these problems be fixed now.

        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.

I agree completely.  Why then is there a conc-name feature (with a particular
default) for automatically generated functions and not for those explicitly
written?
-------