* 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
(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
(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
| 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!