From: David Bakhash
Subject: CLOS macros: `with-slots' vs `with-accessors'
Date:
Message-ID: <cxjn24cap66.fsf@engc.bu.edu>
Hi,
In CLOS programming, I find a lot to be redundant. For example, the
`with-slots' and `with-accessors' are redundant if you consider that
slot accessors always pertain to slots. Unless I'm mistaken,
accessors pertain directly to slots, so why would one want to use
`with-accessors'? There's always gonna be a slot that can give you
the right value. Are there speed issues?
dave
From: Erik Naggum
Subject: Re: CLOS macros: `with-slots' vs `with-accessors'
Date:
Message-ID: <3123578561990030@naggum.no>
* David Bakhash <·····@bu.edu>
| In CLOS programming, I find a lot to be redundant. For example, the
| `with-slots' and `with-accessors' are redundant if you consider that slot
| accessors always pertain to slots. Unless I'm mistaken, accessors
| pertain directly to slots, so why would one want to use `with-accessors'?
| There's always gonna be a slot that can give you the right value. Are
| there speed issues?
WITH-ACCESSORS lets you name the variables that refer to slots by using
the published interface. WITH-SLOTS defaults to using the name of the
slots, although you may name them otherwise at will, so you will use
information internal to the class definition. you use them in the same
circumstances that you would use the accessor or the slot, respectively.
I use WITH-ACCESSORS in code that should not know about the class
internals, and WITH-SLOTS in code that depends on it, anyway, such as
PRINT-OBJECT or SLOT-UNBOUND methods and other such obvious internals.
BTW, note that an accessor method need not refer directly to a slot, so
your assumption does not hold. an accessor can compute the value from
other slots. it could also have been a slot once, now superseded by
changes to the class, but you would want to make such changes as painless
as possible by keeping backward compatibility with the published
interface and either compute a new value or provide a default value or
whatever.
hm. reading your article over, it seems that you think that an accessor
is a special kind of method that accesses slots. while true in the
special (although most usual) case, an accessor is better viewed as a
method on the class that returns the value of a slot, by _default_, but
any method on the class that returns a value that relates _directly_ to
the state of the object (that is, the value would not change until the
state of the object changed), may properly be termed an accessor. it
would also be a reasonable requirement if an accessor returned whatever
value it was set to by the last (setf <accessor>). it would make sense
to refer to an accessor as a "reader" ("getter") or "writer" ("setter")
if it didn't support this symmetry. again, however, such a function need
not refer to _slots_ per se, only directly to the state of the object.
an example (I've seen this somewhere, but forget the source) might be a
class of colored objects, and an accessor SAME-COLOR-P, which returned
NIL if the colors were different, and the color if they were the same.
it would make sense to make this method setf'able, to set the color of
all the objects at the same.
#:Erik
--
Nie wieder KrF! Nie wieder KrF! Nie wieder KrF! Nie wieder KrF!