[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: accessor functions
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
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