Subject: Re: is CLOS reall OO? From: Erik Naggum <clerik@naggum.no> Date: 1998/05/05 Newsgroups: comp.lang.lisp Message-ID: <3103318695270771@naggum.no> * 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 callers. #:Erik -- Support organized crime: use Microsoft products!