Subject: Re: CLOS macros: `with-slots' vs `with-accessors' From: Erik Naggum <email@example.com> Date: 1998/12/25 Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * David Bakhash <email@example.com> | 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!