Subject: Re: CLOS macros: `with-slots' vs `with-accessors'
From: Erik Naggum <>
Date: 1998/12/25
Newsgroups: comp.lang.lisp
Message-ID: <>

* David Bakhash <>
| 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

  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.
  Nie wieder KrF!  Nie wieder KrF!  Nie wieder KrF!  Nie wieder KrF!