Hello all,
I'm starting to feel confortable with common lisp and I would like to
learn object oriented programming with CLOS.
I still have difficulties to understand the point of OOP. I think this
feeling is stronger since I've started to learn LISP. I believe LISP
provides enough abstraction for what I want to do. Can someone
indicated me when/why it makes sense to use it? Is OOP a hype?
On the practical side:
If I create a class site and a class document. A site may have several
documents so site is a superclass of document. I decide to create an
instance of site called 'mysite.
How do I add documents instances, which inherits slots from the
'mysite instance?? Is there a way to do something like (make-instance
'document ( 'mysite ) :initarg1 'initagr1...:initargn 'initargn) to
inherits the dynamic value of the instance 'mysite?
Thank you!
>>>>> On 29 Mar 2002 06:40:54 -0800, Delaregue ("Delaregue") writes:
Delaregue> Hello all,
Delaregue> I'm starting to feel confortable with common lisp and I would like to
Delaregue> learn object oriented programming with CLOS.
Delaregue> I still have difficulties to understand the point of OOP. I think this
Delaregue> feeling is stronger since I've started to learn LISP. I believe LISP
Delaregue> provides enough abstraction for what I want to do. Can someone
Delaregue> indicated me when/why it makes sense to use it? Is OOP a hype?
Object oriented programming is just a way of organizing your code by
modeling it around the data (the "objects") that are to be manipulated.
Delaregue> On the practical side:
Delaregue> If I create a class site and a class document.
Delaregue> A site may have several documents so site
Delaregue> is a superclass of document.
Maybe a "site" and a "document" are not the same kind of thing,
or maybe they are. You have figure that out and decide.
Maybe a SITE is container of DOCUMENTs, but it not itself a DOCUMENT.
In that case the two classes might not be related to each other at all.
Or maybe all DOCUMENTs can contain other DOCUMENTs, and a SITE is
therefore a DOCUMENT. But a SITE is more than a plain DOCUMENT;
it does some other stuff, too. So in this design, DOCUMENT is a
superclass of SITE. (SITE is a subclass of DOCUMENT, because it
proceeds from DOCUMENT. The directionality of the class tree is
named the other way around from the terminology you thought.)
Delaregue> I decide to create an instance of site called 'mysite.
Delaregue> How do I add documents instances, which inherits slots from the
Delaregue> 'mysite instance?? Is there a way to do something like (make-instance
Delaregue> 'document ( 'mysite ) :initarg1 'initagr1...:initargn 'initargn) to
Delaregue> inherits the dynamic value of the instance 'mysite?
CL> (defclass document ()
((documents :accessor documents
:initarg :documents
:initform nil)
(contents :accessor contents
:initarg :contents
:initform nil)))
#<STANDARD-CLASS DOCUMENT 2102C63C>
CL> (defclass site (document)
((site-name :initarg :name
:initform "Unnamed Site"
:accessor site-name)))
#<STANDARD-CLASS SITE 204065B4>
CL> (setq s (make-instance 'site :name "Example"
:contents (list "Welcome to my site." "Enjoy your visit.")))
#<SITE 203FDD54>
CL> (setq d (make-instance 'document
:contents (list "Everything you always wanted to know"
"about cous-cous.")))
#<DOCUMENT 2041500C>
CL> (setf (documents s) (list d))
(#<DOCUMENT 2041500C>)
CL> (describe s)
#<SITE 203FDD54> is a SITE
SITE-NAME "Example"
DOCUMENTS (#<DOCUMENT 2041500C>)
CONTENTS ("Welcome to my site." "Enjoy your visit.")
CL> (documents s)
(#<DOCUMENT 2041500C>)
CL> (dolist (doc (documents s))
(describe doc))
#<DOCUMENT 2041500C> is a DOCUMENT
DOCUMENTS NIL
CONTENTS ("Everything you always wanted to know" "about cous-cous.")
"Delaregue" <·········@netscape.net> wrote in message
·································@posting.google.com...
> Hello all,
>
> I'm starting to feel confortable with common lisp and I would like to
> learn object oriented programming with CLOS.
>
> I still have difficulties to understand the point of OOP. I think this
> feeling is stronger since I've started to learn LISP. I believe LISP
> provides enough abstraction for what I want to do. Can someone
> indicated me when/why it makes sense to use it?
There are situations where `OOP' is the correct abstraction.
> Is OOP a hype?
Largely. Not completely.
> On the practical side:
> If I create a class site and a class document. A site may have several
> documents so site is a superclass of document.
No. A site might `contain' several documents, or a site might be
`composed' of several documents, but documents and sites are two
different sorts of things.
You really want to consider the `is-a' relationship when designing
classes. For instance, a `car' is a `vehicle', a `toyota'
is a `car'.
On 29 Mar 2002 06:40:54 -0800,
Delaregue <·········@netscape.net> wrote:
>
> On the practical side:
> If I create a class site and a class document. A site may have several
> documents so site is a superclass of document.
actually, no.
a site *has* documents, but a document *is not* a site.
if you use *has*, you usually implement a collection of the objects.
if you use *is a*, you usually create the left hand side as a
subclass of the right hand side.
--
Stefan Schmiedl
Approximity GmbH http://www.approximity.com
Research & Development ·············@approximity.com
Loreleystr. 5, 94315 Straubing, Germany
Tel. (0 94 21) 74 01 06, Fax (0 94 21) 74 01 21
shhhh ... I can't hear my code!
> I still have difficulties to understand the point of OOP. I think this
> feeling is stronger since I've started to learn LISP. I believe LISP
> provides enough abstraction for what I want to do. Can someone
> indicated me when/why it makes sense to use it? Is OOP a hype?
>
"oop" is the idea that probrams organized their data into "objects".
exactly what one's definition of an object is however up to debate.
the idea is that data is interacted with as an object.
however I consider it false to associate oop with oo-languages, as it is
possible in an oo-language to write code that does not treat its data as
objects and surely possible to write code in a non-oo langage that treats
its data as objects...
sometimes this is appropriate, sometimes it is not...
consider you have a range of blocks that you want to allocate, you can
store data in the blocks telling their usage status or you can store it in
a bitamp.
in a bitmap it is faster as you have the data all in one place and it is
simpler to preform a lookup.
with blocks you have to iterate over all the blocks and get their usage
status (or consider for example that the blocks are not readily available).
this I consider an argument against oop in all cases.
consider you are managing an entity tree possibly for a physics engine, in
this case oop is better...
it is hyped, and it is useful to not use it sometimes, but it is useful
others.
personally I am not so fond of the class/inheritance system (as I have
imagined one I consider better, at least for my own projects).
in classes it is not possible to really change things on a per object
basis, and it is not really possible to "emulate" objects by passing a
structurally similar equivalent...
with inheritence you would have to specify "mammal", but in my mind it
should be possible to define "warm blooded creature" which may also allow
birds.
Delaregue wrote:
> I still have difficulties to understand the point of OOP. I think this
> feeling is stronger since I've started to learn LISP. I believe LISP
> provides enough abstraction for what I want to do. Can someone
> indicated me when/why it makes sense to use it? Is OOP a hype?
If the data you are modeling fits into an inheritance hierarchy with
behavior shared between levels (and it had better, else why use
inheritance), then OOP is a win. OOP in the Lisp style is probably also a
win when using metaclasses to do aspect-oriented programming and other
exotic programming tasks, too. It is not a useless piece of functionality.
However, given the powerful set of data type choices by which objects can
be modeled in Lisp, OOP is probably not as necessary as in other systems.
Back when I was using Smalltalk, everything looked like an object because
everything WAS an object. You often got into situations where you really
wanted a functional style or merely a stupid structure, yet you could only
model the thing as a full-blown object. The lack of multiple inheritance
caused you to pass objects back and forth to achieve the simplest shared
results. In many cases, it amounted to either overkill or a mangling the
meaning inherent in the system. I actually tried to design a syntax and
structure so that functions, disembodied from individual objects could
exist and be called properly (I also tried to design multi-methods,
optional arguments and macros, too, but I digress :-). OOP was a blessing
in some cases, but not in all cases.
The beauty of Lisp is precisely that it IS a multi-paradigm language. If
the OOP fits, wear it. Otherwise use, functional, procedural,
event-driven, knowledge-based, data-driven, or whatever you can think of
(and perhaps whip up an infrastructure for). And as a bonus, it all plays
together syntactically and, if you're clever enough, semantically, as well.
So as I started this rant, if your object can be modeled as an inheritance
hierarchy, go ahead and use CLOS. Otherwise stick with a simpler structure.
faa
P.S. Modeling containment by inheritance (as you suggest sites "having"
documents would do) is almost always a mistake. Better to have a slot in
the site item that holds a sequence of documents that belong to the site or
a hash table that maintains a maping of sites to documents. If you need a
reference to the site of a given document, think of pointing the document
back to the site item, and getting the documents associated with a given
site by a filtering operation on the set of documents Maintaining the
document collection (and finding a given document without knowing the site)
is a bigger pain than maintaining a single reference to the site in a given
document. Only if the number of documents starts to get realy large do you
need to start adding specialized structure to map the site to the
documents. In any case, not knowing anything else about sites or
documents, you probably don't need to use OOP. Simple structures would
suffice.
·········@netscape.net (Delaregue) writes:
> Hello all,
>
> I'm starting to feel confortable with common lisp and I would like to
> learn object oriented programming with CLOS.
>
> I still have difficulties to understand the point of OOP. I think this
> feeling is stronger since I've started to learn LISP. I believe LISP
> provides enough abstraction for what I want to do. Can someone
> indicated me when/why it makes sense to use it? Is OOP a hype?
>
> On the practical side:
> If I create a class site and a class document. A site may have several
> documents so site is a superclass of document. I decide to create an
> instance of site called 'mysite.
> How do I add documents instances, which inherits slots from the
> 'mysite instance?? Is there a way to do something like (make-instance
> 'document ( 'mysite ) :initarg1 'initagr1...:initargn 'initargn) to
> inherits the dynamic value of the instance 'mysite?
OOP is very powerful, but only when used correctly, and in the right
circumstances. Others have pointed out the problems with your
example; a big part of learning to use OOP well is learning to have a
feel for how problems should be broken into classes and generic
functions. Well, both how, and when. I'd suggest you get a book on
object-oriented style, &/or read a significant OO program. Sometimes
people can figure out good OO style themselves, but sometimes the
style they invent is horrid, and they conclude that OOP is bankrupt.
The big thing to watch out for is that you're not just putting sugar
over spaghetti logic. [ eww, sugared spaghetti ... ]
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
·········@netscape.net (Delaregue) wrote in message news:<····························@posting.google.com>...
> Hello all,
>
> I'm starting to feel confortable with common lisp and I would like to
> learn object oriented programming with CLOS.
>
> I still have difficulties to understand the point of OOP. I think this
> feeling is stronger since I've started to learn LISP. I believe LISP
> provides enough abstraction for what I want to do. Can someone
> indicated me when/why it makes sense to use it? Is OOP a hype?
No, but it can be overused or misuse, like many things in many
languages. E.g. in Lisp, off the top of my head, it's easy to overuse
or misuse whizzy features like built-in lists, exceptions, macros, and
dynamic typing, as well as less glamorous features like global
variables. In all these cases the potential for misuse or overuse
doesn't mean the feature is bad.
> On the practical side:
> If I create a class site and a class document. A site may have several
> documents so site is a superclass of document. I decide to create an
> instance of site called 'mysite.
> How do I add documents instances, which inherits slots from the
> 'mysite instance?? Is there a way to do something like (make-instance
> 'document ( 'mysite ) :initarg1 'initagr1...:initargn 'initargn) to
> inherits the dynamic value of the instance 'mysite?
Just like several other responses, I'll say "ouch" here. With deep
feeling.
The fancy academic name for the principle you're violating is the
Liskov substitution principle, roughly "an object of a derived class
should be usable wherever an object of its base class is". In order to
make this hold, good inheritance relationships tend to match "is a"
relationships, as others have said. If you follow this principle --
especially if you're in a problem domain where it's easy to find
relationships which fit this principle -- then OO will be your friend
and good things will happen to your code. If you don't, then either
you will discover a hitherto unknown principle of software
architecture, or much more likely you'll become the 4,424,312th person
to rediscover how pointless, bewildering, broken and ugly bad OO code
can be.
(If you have a "has a" relationship, you don't need or want
inheritance to express it, any more than you need or want a global
variable to transmit a function argument, a string to represent a
floating point value, or twelve different cut-and-pasted copies of the
same code to represent your logic for printing dates. Using the wrong
language constructs to implement your abstractions can rapidly turn an
otherwise manageable programming problem into a horrendous mess.)
In the past I also didn't understand much of OOP, but after I learned Eiffel, everything became easy. Even if you don't end up using the language, it's a very good language for learning OOP. In my opinion it's much easier to learn the concept by using a language instead of learning the theory abstractly.