Subject: Re: is CLOS reall OO?
From: Erik Naggum <>
Date: 1998/05/05
Newsgroups: comp.lang.lisp
Message-ID: <>

* Kevin Haddock
| Hi, I'm somewhat new to lisp but upon looking into CLOS it would appear
| that the primary way to set slot values is with setf.

  not necessarily.  let's consider the two typical cases:

(defclass class-with-setter-getter ()
  (some-slot :reader get-some-slot
             :writer set-some-slot
             :initform 42))

(defvar *setter-getter-instance* (make-instance 'class-with-setter-getter))

(get-some-slot *setter-getter-instance*) => 42
(set-some-slot 41 *setter-getter-instance*) => 41
(get-some-slot *setter-getter-instance*) => 41

(defclass class-with-accessor ()
  (some-slot :accessor some-slot
             :initform 42))

(defvar *accessor-instance* (make-instance 'class-with-accessor))

(some-slot *accessor-instance*) => 42
(setf (some-slot *accessor-instance*) 41) => 41
(some-slot *accessor-instance*) => 41

  BTW: note the order of arguments in SET-SOME-SLOT.

| Now I know that setf is a generic function

  no, it isn't.  SETF is a macro.

| ... isn't it fundamentally wrong for one object to be tinkering around
| with another's private data?

  well, objects don't do any tinkering to begin with, they just are, so
  let's presume you meant that some _code_ somewhere "tinkers" with some
  object's "private" data.

  however, if you think it is "wrong" to do something, then you just don't
  do that.  if you want the compiler to smack you in the face if you do it
  anyway, I'd say you have an attitude problem that needs readjustment
  before you resume writing code.

  some purportedly object-oriented languages are designed specifically for
  people who love to be smacked in the face when they lie to the compiler.
  bondage and discipline go hand in hand with very strict rules of privacy
  and all that weird deviant stuff.  CLOS isn't like that.

  CLOS communicates the _intent_ of hiding differently, but if you look for
  the ways to express yourself in CLOS, it would very hard indeed _not_ to
  see that CLOS code is just as concerned with proper etiquette and access
  rights as the anal-retentive languages.  if a slot has no :WRITER option,
  that's a fairly good sign you should not be writing to this slot.  ditto
  for :READER or :ACCESSOR.  in essence, if you use the function SLOT-VALUE
  in your code, you either have the right to do so, or you're trespassing.
  _how_ to determine whether you have that right or is trespassing is a
  question of policy that you find paralleled in communities everywhere:
  whether to use armed guards with Rotweilers to whom you have to declare
  people to be your friends, whether to fence yourself in but just lock the
  gates, whether to have open access and everybody just keeps an eye on it
  all, or whether to let giant open areas be accessible to the public as
  long as they behave well.  obviously, by using words like "tinkering
  about with other's private data", you imply a strong sense of privacy and
  an attitude towards heavy policing and ID cards for the children of your
  friends and such.  you might actually feel _unsafe_ in a CLOS world where
  people are just expected to show good taste, unless you feel you can
  trust them.  it's a matter of what kind programmers you live amongst, I
  guess.  if you live among thieves and bums who steal and rob you, by all
  means go for the compiler who smacks them in the face.  if you live among
  nice people who you would _want_ to worry about a red-hot plate they can
  see inside a kitchen window or a broken window they need to look inside
  your house before reporting as a crime (serious bug), you wouldn't want
  the kind of armor-plating that you might want in the 'hood.  that doesn't
  mean the _need_ for privacy is any different.  it's just that in C++ and
  the like, you don't trust _anybody_, and in CLOS you basically trust
  everybody.  the practical result is that thieves and bums use C++ and
  nice people use CLOS.  :)

| What happens, say, if I create a class and all throughout my code I set
| one of it's slots with setf, then later in the development I decide that
| that slot will not be an actual slot, but derived from several other
| slots and now just merely a method.

  I infer from this that you would use SLOT-VALUE.  the :READER and :WRITER
  and :ACCESSOR options in DEFCLASS automatically create methods for you,
  so you don't have use SLOT-VALUE (although those methods will effectively
  do just that).  there is no difference between such a method and any
  other method.

| Do I have to go all throughout my program and change the setf's into
| method calls?

  presuming you don't use SLOT-VALUE directly: no, you define a SETF method
  for the accessor method that does the right thing, and recompile the

  Support organized crime: use Microsoft products!