RFC about "Object Oriented Programming in Common Lisp"
vsync
> I'm a beginner Lisp enthusiast who's looking for comments about the
> above mentioned book, to decide whether it's worth buying. I've
> read/understood/experimented with Paul Graham's "ANSI Common Lisp", so
> I'm very familiar with CL.
I am at exactly the same stage you are.
> Coming from a C++/Java background, I'm deeply routed in OOP techniques
> (for better or for worse?!), so I've already played with CLOS. However,
> it seemed to me that doing things in CLOS is sometimes fundamentally
> different from the way you would do things in C++. Thus I thought the
Absolutely. It took a bit of getting used to, but I love the way you
can dispatch on any or all of the arguments, without having to specify
that "method X goes with class Y and only class Y", as in C++ or Java.
CLOS allows me to just write good code without getting paranoid about
my object structure beforehand.
> On the subject, another good question would be: should I try to program
> in Common Lisp using OOP techniques, or should I stick to the more
> traditional functional programming paradigm of Lisp? What has worked
> for you guys?!
As I said, I am also a beginner, but in a recent project, I initially
tried to write everything without any OOP code. Then I realized OO
was really the only way to express it, so I wrote it using CLOS, and
was quite pleased with the results. Portions of the code, though,
were just ordinary functions, and so I just used defun. That's what I
love about Common Lisp and CLOS: I'm not forced into writing OO code
because some language designer wants me to, but if the situation is
appropriate, it's easy and powerful.
I discovered a number of structural differences between Java (my other
main OO language) and CLOS. For example, since CLOS allows multiple
inheritance and you can dispatch on any argument, the super() method
has no place, and implementing something analogous can take a little
more work if after-methods are not appropriate. On the other hand,
things such as Java's "interface" are generally unnecessary in CLOS,
because of the way methods are not associated so tightly with a
particular class.
Many of the differences are simply stylistic, or just make it better
to organize your object relationships in a different manner. On the
whole, though, CLOS is much more powerful than Java or the bloated
lumbering beast that is C++.
--
vsync
http://quadium.net/ - last updated Mon Jun 12 23:31:13 MDT 2000
Orjner.
Steven M. Haflich
Michael Abd-El-Malek wrote:
> Coming from a C++/Java background, I'm deeply routed in OOP techniques
> (for better or for worse?!), so I've already played with CLOS.
When C++ is your hammer, everything looks like a thumb.
vsync
> When C++ is your hammer, everything looks like a thumb.
ROFL! Hope you don't mind getting quoted on that...
Steven M. Haflich
>
> "Steven M. Haflich" <haf...@pacbell.net> writes:
>
> > When C++ is your hammer, everything looks like a thumb.
>
> ROFL! Hope you don't mind getting quoted on that...
Well, I first posted to comp.lang.c++ a line very much like
this perhaps a decade ago. It has since been widely quoted
with and without and with incorrect attribution. For fun
I just did an Alta Vista search for c++ NEAR hammer NEAR thumb
and got more hits than I cared look at.
No, I don't mind being quoted, but spell the name right.
Also, I want to go on record that I am _probably_ not the
originator of the "hammer ... thumb" punchline. I _think_ a
friend first used it (obviously in a different context) more
than 35 years ago, but I'm not really sure. I don't want this
to haunt me if I ever decide to run for president...
Now what about Java? Perhaps we can collaborate on a pithy
putdown. An effective putdown needs to have _some_ basis in
reality, needs to be short, and needs to have some unexpected
twist that makes it funny.
I've thought of this:
When Java is your hammer, you can get any size or shape thumb
you want, for free, in any quantity, and the language generously
prevents you from hitting more than one thumb per swing.
Now, this has some promise (including the dig at Swing) but
it's a little too long and only makes sense following the
C++ line. Since it's weaker than the C++ line, it really
doesn't stand up; a followup joke needs to be stronger than
the original.
Anyone have any ideas for tweaks?
Steven M. Haflich
vsync wrote:
>
> "Steven M. Haflich" <haf...@pacbell.net> writes:
>
> > Now what about Java? Perhaps we can collaborate on a pithy
> > putdown. An effective putdown needs to have _some_ basis in
>
>
> > When Java is your hammer, you can get any size or shape thumb
> > you want, for free, in any quantity, and the language generously
> > prevents you from hitting more than one thumb per swing.
>
>
> > Now, this has some promise (including the dig at Swing) but
> > it's a little too long and only makes sense following the
> > C++ line. Since it's weaker than the C++ line, it really
> > doesn't stand up; a followup joke needs to be stronger than
> > the original.
>
> touch out of place. I love the Swing punchline though.
>
> I assume you've seen those lists about "if <language> was a car" and
> "how to shoot yourself in the foot with <language>"?
Java is a really efficient language. It cleverly arranges your feet
into a single line so you can get both with one bullet.
Michael Abd-El-Malek
I'm a beginner Lisp enthusiast who's looking for comments about the
above mentioned book, to decide whether it's worth buying. I've
read/understood/experimented with Paul Graham's "ANSI Common Lisp", so
I'm very familiar with CL.
it seemed to me that doing things in CLOS is sometimes fundamentally
different from the way you would do things in C++. Thus I thought the
experience with it?
On the subject, another good question would be: should I try to program
in Common Lisp using OOP techniques, or should I stick to the more
traditional functional programming paradigm of Lisp? What has worked
for you guys?!
of being picky! But do tell me if any of my assumptions/statements are
unappropriate :)
Thanks,
Michael Abd-El-Malek
Barry Margolin
Michael Abd-El-Malek <mabd...@engmail.uwaterloo.ca> wrote:
>Hi,
>I'm a beginner Lisp enthusiast who's looking for comments about the
>above mentioned book, to decide whether it's worth buying. I've
>read/understood/experimented with Paul Graham's "ANSI Common Lisp", so
>I'm very familiar with CL.
>Coming from a C++/Java background, I'm deeply routed in OOP techniques
>(for better or for worse?!), so I've already played with CLOS. However,
>it seemed to me that doing things in CLOS is sometimes fundamentally
>different from the way you would do things in C++.
Yes, the CLOS approach to OO is quite different from some other OO
languages. The notion of generic functions and multiple dispatch rather
than traditional message dispatch can be a little difficult to get used to
if you're used to thinking along the lines of methods "belonging" to
classes. But it allows some techniques that can be difficult to achieve in
more traditional OO languages.
> Thus I thought the
>above mentioned book would be worthwhile. Does anyone here have any
>experience with it?
It's an excellent introduction to the subject matter.
>On the subject, another good question would be: should I try to program
>in Common Lisp using OOP techniques, or should I stick to the more
>traditional functional programming paradigm of Lisp? What has worked
>for you guys?!
As with C++ vs. C, the OO facilities can be a big help in complex
applications, especially those that need to be easily extensible. For
simple applications, though, I think it often complicates things more than
is necessary, so I wouldn't recommend using OOP all the time.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Rainer Joswig
Abd-El-Malek <mabd...@engmail.uwaterloo.ca> wrote:
> Coming from a C++/Java background, I'm deeply routed in OOP techniques
> (for better or for worse?!), so I've already played with CLOS. However,
> it seemed to me that doing things in CLOS is sometimes fundamentally
> different from the way you would do things in C++. Thus I thought the
> above mentioned book would be worthwhile. Does anyone here have any
> experience with it?
AFAIK, the above mentioned book is not much about CLOS,
contrary to what the title indicates.
> On the subject, another good question would be: should I try to program
> in Common Lisp using OOP techniques, or should I stick to the more
> traditional functional programming paradigm of Lisp? What has worked
> for you guys?!
Depends on waht you want to do. Read for example PAIP from Norvig
- he tries to use Common Lisp mostly without CLOS.
On the other hand most larger Lisp libraries are using CLOS
in some way or another.
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinhöft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: mailto:rainer...@ision.net WWW: http://www.ision.net/
vsync
> Now what about Java? Perhaps we can collaborate on a pithy
> putdown. An effective putdown needs to have _some_ basis in
Hey, don't go too hard on Java, I like it too...
> When Java is your hammer, you can get any size or shape thumb
> you want, for free, in any quantity, and the language generously
> prevents you from hitting more than one thumb per swing.
Ba-dum-CHING!
> Now, this has some promise (including the dig at Swing) but
> it's a little too long and only makes sense following the
> C++ line. Since it's weaker than the C++ line, it really
> doesn't stand up; a followup joke needs to be stronger than
> the original.
It's not so much the length, I think, but the middle part seems a
touch out of place. I love the Swing punchline though.
I assume you've seen those lists about "if <language> was a car" and
"how to shoot yourself in the foot with <language>"?
--
Martin Cracauer
>Java is a really efficient language. It cleverly arranges your feet
>into a single line so you can get both with one bullet.
But only after you made your low-level into a wrapper object that the
line container can hold.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Erik Naggum
| Coming from a C++/Java background, I'm deeply routed in OOP
| techniques (for better or for worse?!), so I've already played with
| CLOS. However, it seemed to me that doing things in CLOS is
| sometimes fundamentally different from the way you would do things
| in C++.
OOP techniques are generally good, when applied within reason. C++
is a bad instantiation of them and encourages bad use of OOP
techniques. CLOS is a good instantiation of them and discourages
bad use of OOP techniques. This leads to some cultural clashes.
| On the subject, another good question would be: should I try to
| program in Common Lisp using OOP techniques, or should I stick to
| the more traditional functional programming paradigm of Lisp? What
| has worked for you guys?!
If you can shed the C++ heritage and ignore the urge to let classes
_own_ methods, as well as ignore the urge to control _ownership_ of
data, you'll have no problems. Since more than half of C++'s stupid
implementation of OOP is about ownership control, this may be hard.
#:Erik
--
If this is not what you expected, please alter your expectations.
Jukka Kakko
Michael Abd-El-Malek wrote:
>
> Hi,
> I'm a beginner Lisp enthusiast who's looking for comments about the
> above mentioned book, to decide whether it's worth buying. I've
> read/understood/experimented with Paul Graham's "ANSI Common Lisp", so
> I'm very familiar with CL.
> Coming from a C++/Java background, I'm deeply routed in OOP techniques
> (for better or for worse?!), so I've already played with CLOS. However,
> it seemed to me that doing things in CLOS is sometimes fundamentally
> different from the way you would do things in C++. Thus I thought the
> above mentioned book would be worthwhile. Does anyone here have any
> experience with it?
Wellcome !
I am just another beginner, so I won't shoot you anywhere.
If you mean Sonya E. Keene's book:
http://www.amazon.com/exec/obidos/ASIN/0201175894/qid%3D961055525/002-5372867-0248818
It is just what it says: "A Programmers Guide to the Common Lisp Object
System"
I think it is a very good book. I have read it twice. It explains enough
to
get anyone a good start for understanding CLOS. It was the the book that
teached
me the right practices, protocol-orientation, advertised interface...
Try to read it like you don't know anything about object-oriented
programming.
> On the subject, another good question would be: should I try to program
> in Common Lisp using OOP techniques, or should I stick to the more
> traditional functional programming paradigm of Lisp? What has worked
> for you guys?!
I think you should not try too hard to use OOP techniques. Read and
understand
the concepts. Whenever you need a structure or a thing that has
properties
make it an object. After a while it happens quite naturally. Common Lisp
is
rich language itself. Usually the objects you make are about the problem
you have.
Arrays, hash-tables, and yes, even lists are already there. Because
prototyping
is so easy with Common Lisp you can start making objects very early.
Redefining classes saves your data in objects, only changes are
propagated.
I think this is beautiful. You can incrementally create your system
using
very short cycles.
> And please, I'm a beginner so don't shoot me down if you're in the mood
> of being picky! But do tell me if any of my assumptions/statements are
> unappropriate :)
> Thanks,
> Michael Abd-El-Malek
Your assumptions/statements were appropriate.
Regards,
Jukka Kakko
(speaking for myself)
Pierre R. Mai
> Hi,
> I'm a beginner Lisp enthusiast who's looking for comments about the
> above mentioned book, to decide whether it's worth buying. I've
> read/understood/experimented with Paul Graham's "ANSI Common Lisp", so
> I'm very familiar with CL.
Let's first get some confusion out of the way, since I think that some
replies apply (<g>) to another book with a similar title. There is:
* Keene, Sonya E.: Object Oriented Programming in Common Lisp
- A Programmers Guide to the Common Lisp Object System (24h)
http://www.amazon.com/exec/obidos/ASIN/0201175894/
http://www.amazon.de/exec/obidos/ASIN/0201175894/
which is a very good book for someone familiar with CL who wants to
learn about CLOS, and programming using CLOS constructs.
There is also
* Slade, Stephen: Object-Oriented Common Lisp (24h)
http://www.amazon.com/exec/obidos/ASIN/0136059406/
http://www.amazon.de/exec/obidos/ASIN/0136059406/
which is more comparable to Paul Graham's ANSI Common Lisp, and
therefore probably isn't what you are looking for.
> Coming from a C++/Java background, I'm deeply routed in OOP techniques
> (for better or for worse?!), so I've already played with CLOS. However,
> it seemed to me that doing things in CLOS is sometimes fundamentally
> different from the way you would do things in C++. Thus I thought the
> above mentioned book would be worthwhile. Does anyone here have any
> experience with it?
The book by Sonya E. Keene is probably a very good first step to
getting to know the CLOS way of OOP. Additionally I'd get a copy of
* Kiczales, Gregor et al: The Art of the Metaobject Protocol (2-3 days)
http://www.amazon.com/exec/obidos/ASIN/0262610744/
http://www.amazon.de/exec/obidos/ASIN/0262610744/
which will give you additional insight into CLOS, the MOP, and -- since
CLOS is implemented via CLOS -- it will give you some very nice
examples of how to go about designing CLOS programs (i.e. protocol
design, as the CLOS community calls it). Although it's subject matter
is the MOP, this is IMHO one of the best books to learn about CLOS
programming and design techniques.
> On the subject, another good question would be: should I try to program
> in Common Lisp using OOP techniques, or should I stick to the more
> traditional functional programming paradigm of Lisp? What has worked
> for you guys?!
IMHO since you already did OOP programming in lesser languages,
you will have to do both:
- Try to think less in terms of objects and methods: Not
everything is an object, and not everything is a generic function.
Use them at first only for higher-level objects, most low-level
stuff is better of without OOP, or with a slim OOP wrapper.
E.g. if you were to redo CL, you'd implement lists and vectors
"without" CLOS, but you might want to create wrapper objects in such
a way that you can get your class-hierarchy of sequences, lists and
vectors, so you can write generic functions that unify access to
lists and vectors (CL itself does it this way, though via some MOP
trickery with built-in classes).
A good way to approach this is to think about protocols that you
want implemented. That will let you focus on the stuff that might
be variable, the stuff that will stay constant and the interfaces to
all of it. Then you can decide where to use generic functions and
classes to give you the needed flexibility, and where not to use it.
As an example: It wouldn't make sense to make car or cdr a generic
function, since there will only ever be one useful implementation of
it for singly-linked lists, and for other data structures it doesn't
make sense to offer those accessors. OTOH it might make sense to
make elt a generic function, since it offers a service that makes
sense on a number of ordered data structures.
- You will have to write a couple of programs using CLOS, before you
will see what the wrong and right ways of using CLOS will be. Trust
me, you'll get a number of programs wrong (suffering from objectitis
and flat inheritance graphs), but then you'll begin to see the
light.
Regs, Pierre.
PS: The links to Amazon above are NOT part of some kind of partner
program, so I won't profit from books sold through them.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
David Bakhash
> | On the subject, another good question would be: should I try to
> | program in Common Lisp using OOP techniques, or should I stick to
> | the more traditional functional programming paradigm of Lisp? What
> | has worked for you guys?!
>
> If you can shed the C++ heritage and ignore the urge to let classes
> _own_ methods, as well as ignore the urge to control _ownership_ of
> data, you'll have no problems. Since more than half of C++'s stupid
> implementation of OOP is about ownership control, this may be hard.
yes. in this thread it seems that several people have mentioned that
methods don't belong to classes in the same way that they do in every
most other OO langages. But I actually think this is a very minor
feature in comparison to why I like CLOS.
I think that the Franz marketing hype, namely "Dynamic Objects" is
among the main reasons I like CLOS. It's true that only on very rare
occations do I actually redefine classes during run-time, change the
allocation of slot from :instance to :class, etc., but consider that a
lot of the work programers do is in the CL environment, right from the
REPL. so CL's dynamic redefinition abilities are quite amazing.
You'll have to see, and use, the magic to appreciate it. There's
nothing like it out there. When I want to _do_ something in CL, I
just _do_ it. There's very little overhead to _doing_ stuff. You
don't even have to edit and save a file. You don't have to rebuild
your system (often). CL really lets you inside itself, and CLOS is
just part of CL.
Another feature of CLOS, not part of ANSI CL but available in many
CLOS implementations, is MOP, which I have personally gotten a lot of
mileage out of for transparent programming, specifically for
persistence.
Basically, what I'm saying is that CLOS is good _because_ the rest of
CL is good. It's not the features of CLOS so much as the language
features of CL (such as macros) that make the coupling of CLOS with
the language very nice.
dave
David Bakhash
> | On the subject, another good question would be: should I try to
> | program in Common Lisp using OOP techniques, or should I stick to
> | the more traditional functional programming paradigm of Lisp? What
> | has worked for you guys?!
>
> If you can shed the C++ heritage and ignore the urge to let classes
> _own_ methods, as well as ignore the urge to control _ownership_ of
> data, you'll have no problems. Since more than half of C++'s stupid
> implementation of OOP is about ownership control, this may be hard.
yes. in this thread it seems that several people have mentioned that
methods don't belong to classes in the same way that they do in every
most other OO languages. But I actually think this is a very minor
feature in comparison to why I like CLOS.
I think that the Franz marketing hype, namely "Dynamic Objects" is
among the main reasons I like CLOS. It's true that only on very rare
occasions do I actually redefine classes during run-time, change the
allocation of slot from :instance to :class, etc., but consider that a
lot of the work programmers do is in the CL environment, right from the
Thom Goodsell
>
[snip]
> On the subject, another good question would be: should I try to program
> in Common Lisp using OOP techniques, or should I stick to the more
> traditional functional programming paradigm of Lisp? What has worked
> for you guys?!
Do what works for your problem, and feel free to mix programming
paradigms. The last big Lisp project I worked on was a path planner for
autonomous robots. It accepted commands from a user interface, planned
a mission, and communicated with the robot. 70% of the code was written
in functional style, but since we wanted the code to work for multiple
robots, much of the actual planning code was OO. That is the great
thing about Lisp, you can mix and match paradigms in the way most
appropriate for your problem.
Thom
Martin Cracauer
> On the subject, another good question would be: should I try to
> program in Common Lisp using OOP techniques, or should I stick to
> the more traditional functional programming paradigm of Lisp? What
> has worked for you guys?!
Personally I rarely use CLOS in my own projects and many CL libraries
I use don't use it as well. I would prefer a simpler (Smalltalk-like)
class-with-methods mechanism (with multiple inheritance, of course).
I'm not sure that I use a functional approach instead. I just use a
classic functions'n'struct style with rare static data, much reuse of
allocated data structures and I'm happy about the added features Lisp
has to offer for this style (over C).
Please note that my views are often contrary to other posters in this
newsgroup, my whole thinking about programs is not classic "Lispish".
Relativly unopposed should be the advice that you have to look at the
compromise between speed and after-compilation flexibility that CLOS
uses. The whole Gregor Kiczales school of programming is about
pushing decisions back to the latest possible moment so that you don't
limit your options of messing with things and influencing program flow
while the whole system is already shipped/running.
In comparision with most other OO languages, you have slower method
lookup (and slot access), so you probably need to bump the level of
"things" you make CLOS objects of. Also note that the efficiency of
CLOS message lookup varies amoung implementation, not related to their
overall performance relation.
Barry Margolin
Pierre R. Mai <pm...@acm.org> wrote:
>The book by Sonya E. Keene is probably a very good first step to
>getting to know the CLOS way of OOP. Additionally I'd get a copy of
>
>* Kiczales, Gregor et al: The Art of the Metaobject Protocol (2-3 days)
> http://www.amazon.com/exec/obidos/ASIN/0262610744/
> http://www.amazon.de/exec/obidos/ASIN/0262610744/
>
>which will give you additional insight into CLOS, the MOP, and -- since
>CLOS is implemented via CLOS -- it will give you some very nice
>examples of how to go about designing CLOS programs (i.e. protocol
>design, as the CLOS community calls it). Although it's subject matter
>is the MOP, this is IMHO one of the best books to learn about CLOS
>programming and design techniques.
I heartily agree. The book essentially takes you step by step through the
process that the MOP designers used, so you can see the evolution of the
classes and protocols. It's nice to see it unfolding so elegantly.
Courageous
> | program in Common Lisp using OOP techniques, or should I stick to
> | the more traditional functional programming paradigm of Lisp? What
> | has worked for you guys?!
>
> _own_ methods, as well as ignore the urge to control _ownership_ of
> data, you'll have no problems. Since more than half of C++'s stupid
> implementation of OOP is about ownership control, this may be hard.
Which all to often, I've seen reduced to the absurd. To wit:
class SillyClass
{
private:
int i;
float f;
public:
int get_i() { return i; }
float get_f() { return f; }
void set_i (int ix) { i=ix; }
void set_f (float fx) { f=fx; }
};
Doesn't it make you want to puke?
I actually find CLOS to be quite nice. I fail to see how anyone
can think of it as "not object oriented". While it's a bit strangely
jarring at first (coming from the usual background, as it were)
to see methods as being autonomous, it's easy enough to understand
once you start thinking about multimethods.
C/
Marco Antoniotti
vsync <vs...@quadium.net> writes:
> Michael Abd-El-Malek <mabd...@engmail.uwaterloo.ca> writes:
>
> > I'm a beginner Lisp enthusiast who's looking for comments about the
> > above mentioned book, to decide whether it's worth buying. I've
> > read/understood/experimented with Paul Graham's "ANSI Common Lisp", so
> > I'm very familiar with CL.
>
> I am at exactly the same stage you are.
>
> > Coming from a C++/Java background, I'm deeply routed in OOP techniques
> > (for better or for worse?!), so I've already played with CLOS. However,
> > it seemed to me that doing things in CLOS is sometimes fundamentally
> > different from the way you would do things in C++. Thus I thought the
>
> Absolutely. It took a bit of getting used to, but I love the way you
> can dispatch on any or all of the arguments, without having to specify
> that "method X goes with class Y and only class Y", as in C++ or Java.
> CLOS allows me to just write good code without getting paranoid about
> my object structure beforehand.
Just to add to the fun.... :)
I found myself using a lot of
(defun process-foos (foos)
(loop for foo in foos
collect (process-foo (first foo) (rest foo))))
(defmethod process-foo ((op (eql 'zut)) args) ...)
(defmethod process-foo ((op (eql 'zot)) args) ...)
(defmethod process-foo ((op (eql 'zat)) args) ...)
Not that this is the right thing to do all the time, but ... try this
with C++ :) (or Java, or Python)
Cheers
--
Marco Antoniotti ===========================================
David Thornley
Courageous <jkra...@san.rr.com> wrote:
>> | On the subject, another good question would be: should I try to
>> | program in Common Lisp using OOP techniques, or should I stick to
>> | the more traditional functional programming paradigm of Lisp? What
>> | has worked for you guys?!
>>
>Which all to often, I've seen reduced to the absurd. To wit:
>
>class SillyClass
>{
>private:
> int i;
> float f;
>public:
> int get_i() { return i; }
> float get_f() { return f; }
> void set_i (int ix) { i=ix; }
> void set_f (float fx) { f=fx; }
>};
>
>Doesn't it make you want to puke?
>
The set and get functions do provide levels of abstraction that
are useful. It makes it possible to maintain constraints on the
data, and allows a change in implementation while keeping the
interface. (Suppose you were implementing a complex number class,
and kept changing your mind about x-y versus r-theta representation;
given set and get functions, you could change freely without
affecting how the class were to be used.)
Now, in CL there's already no difference. (bar-foo bar) may be a
simple accessor (like above) or may be a calculation, or anything
else for that matter. Therefore, this sort of nonsense is irrelevant
in CL.
>I actually find CLOS to be quite nice. I fail to see how anyone
>can think of it as "not object oriented". While it's a bit strangely
>jarring at first (coming from the usual background, as it were)
>to see methods as being autonomous, it's easy enough to understand
>once you start thinking about multimethods.
>
My experience was that it looked funny at first, but then I started
using it and things just kinda fell into place. Then, when I was
learning C++, I went back to CLOS with something of a "Is that all
there is to CLOS?" attitude. On rechecking, I decided that that
really was all there was (modulo all the neat stuff I hadn't bothered
to use), and that didn't prevent CLOS from being considerably more
powerful than the C++ object system.
Everybody who is thinking about creating some sort of object-oriented
system should use CL with CLOS for at least one fair-sized project,
just to learn how easy it can be.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Barry Margolin
The nice thing about CLOS in this respect is that the normal operator for
setting slots, SETF, expands into a call to the (SETF <slot-name>) generic
function automatically for CLOS slots. So you don't need to make up a
non-standard syntax for setting slots in order to get this level of
abstraction. Dylan is similar, with its <slot>-setter functions.