a) Always. I never use a defun or defstruct, may God smite me down if
    I do.

 b) Sometimes. When appropriate. But sometimes it's just not worth it.

 c) Never. OO is nothing but media hype. It's too bad Common Lisp had
    to get poluted with it.

Obviously a) and c) are pretty extreme. I'm guessing that most folks
will classify their use of CLOS under b) but based on some things I've
read here and elsewhere I'm speculating that there are *some* c) folks
out there and maybe more than I'd expect. And I've got the Java brain
damage bad enough to be inclined to fall into a) so I'm wondering if
there are others. If you do classify your use under b) I'd be further
interested to know how you decide when is appropriate and what makes
it sometimes not worth it.

Finally, if anyone has pointers to source code that is an example of
good Common Lisp style in any of the three categories of CLOS use, I'd
be interested.

-Peter

Although I spent all day today writing code that uses CLOS heavily,
I wouldn't mark myself for any of your poll choices.

Choices (a) and c) are silly, and (b) is loaded with some
kind of weird metric that I don't understand.

I think the only answer that makes sense
-- and it's not on your troll -- err, I mean, poll --
would be: "Experienced Lisp programmers use CLOS when appropriate."
(Wouldn't you assume so, without asking?)

    (defstruct a
      x y)

    (defstruct (b (:include a))
      z)

    (defgeneric grind (x)
      (:method ((x a))
        (+ (a-x x) (a-y x)))
      (:method ((x b))
        (+ (b-z x) (call-next-method)))
      (:method ((x number))
        x))

Secondly, I use functions when I don't intend the behaviour I'm
defining to be extensible, or when there are no obvious objects in the
game.  For instance, I have a function (which Erik would hate, with
good reason) PRETTY-DATE-STRING, which prints a pretty date string.
It takes one optional argument, which is a universal time, the default
being (get-universal-time).  Making it a GF would be kind of strange,
because it has no arguments...

Again, Lisp has been well-designed - there is no syntactic difference
between code which uses GFs and code that uses ordinary functions.
Therefore, if I design using plain functions but then decide I want to
change to GFs, for whatever reason, nothing other than the definitions
of my functions/GFs need change.  Compare with C++, say which has two
syntaxes, forcing a big up-front decision about whether to use
functions of methods, or changes to all client code when that decision
changes. Java seems to have done this somewhat better.

--tim

  An extremely poorly done one that will yield worthless results.

| I'm interested in how experienced Lisp users would describe their use of
| CLOS:

  Please understand that your questions do not exhibit any relationship
  whatsoever to your stated interest.

--
Erik Naggum, Oslo, Norway

generic-functions are generic *functions*, so if it doesn't make sense
for something to be extensible, you use functions.  Additionally,
types aren't the only way to dispatch on something, and CLOS
(correctly) doesn't let you dispatch using the full type system.  For
example, part of an application I'm working on is OO, and another part
does symbol processing.  When the argument you want to dispatch on is
always of type (CONS SYMBOL LIST), generic functions aren't the right
tool.  In this case, we use the symbol's plist for dispatching.

  (deftype symbolic-expression ()
    '(cons symbol list))

  (deftype context ()
    ;; Right now we're using alists, but this could change
    'list)

  (defun frob-expression (symbolic-expression context)
    (check-type symbolic-expression symbolic-expression)
    (check-type context)
    (let ((fn (get (first symbolic-expression) 'frob-function)))
      (check-type fn function)
      (funcall fn symbolic-expression context)))

or, we could force it into an OO paradigm:

  (deftype symbolic-expression ...)
  (deftype context ...)

  (defgeneric frob-expression (symbolic-expression context))
  (defmethod frob-expression ((symbolic-expression list) (context list))
    (check-type symbolic-expression symbolic-expression)
    (check-type context)
    (expression-frobber (first symbolic-expression)
                        (rest symbolic-expression)
                        context))

  (defgeneric expression-frobber (symbol more-expression context))
  (defmethod expression-frobber ((symbol (eql foo)) more-expression context)
    ...)
  (defmethod expression-frobber ((symbol (eql bar)) more-expression context)
    ...)
  (defmethod expression-frobber ((symbol (eql baz)) more-expression context)
    ...)

  ;;; etc

It's not an issue of "worth it" vs "not worth it", it's a matter of
using the correct tools for the correct problem.

So everyone worth listening to will answer (b) and what does that tell
you exactly?

I'm guessing that what you really want to know is how many people are
closer to one end or the other and why.

As far as getting to the meat of the issue, I pretty much agree with Tim
Bradshaw's reponse.  The most wonderful thing about lisp is not having
to make this decision up front.

There can be some case made for the equivalent of (a) in languages where
switching from one paradigm to another requires client code rewrites --
with few exceptions, it results in maximum design flexibility.  Lisp,
OTOH, has that kind of design flexibility by nature, so an upfront
decision is not so very important.  You get a lot of data modularity and
other OO benefits without using CLOS at all.

Michael

-Peter

Or another way: given that I've spent most of my career programming in
an an OO style, my inclination on first opening a new .lisp file is to
to type "(defclass ...". Is that a reasonable idiomatic Lisp approach
or is that baggage from my past that I should try to shed.

Apologies if my earlier post tried to get at this in a too cute, too
eliptical, or just plain too stupid manner.

-Peter

This is actually not true. The common thing between a structure-class and a
standard-class is that they both are subclasses of class. There is no
difference in using them as specializers in a method-definition.

I think structure-classes are best imagined as a mean to optimize your code
by accepting the fact that one loses some flexibility in expressiveness and
comfort.

Some time ago I wrote together with a colleguae a genetic algorithm to do
TSP optimization. Our first version was quickly done and then we sat down
and optimized by changing datastructures and allocation issues which finally
lead to a >30 fold speedup. Finding the *right* datastructure was easy
since after solving the problem we knew what they need and what not. I'm
sure if we would have tried that from the beginning the result would have
been slower, buggier and we would have needed more time to finish it.

Syntactically there is no real difference between both approaches. One could
wrap both, the method definition or the registration of the function with
the symbol-plist into a macro like

(def-expression-frobber foo (more-expression context)
  ...)

which expands to either

(defmethod expression-frobber ((symbol (eql foo)) more-expression
   context)
     ...)

or

(eval-when (:compile-toplevel :execute)
  (setf (get 'foo 'frob-function)
    (lambda (more-expression context)
      ...)))

The CLOS solution is probably a little bit more bloated because you need a
generic function you would not need otherwise. But this is IMHO nothing
critical.

Such a decision (not to use CLOS) might pay off when you may deliver your
application and then are able to rip out CLOS completely. Besides of that I
see no fundamental difference in both approaches.

ciao,
Jochen

  And what would those arguments be?

  You see, you labor under a serious delusion: The languages you think
  about is not /really/ object-oriented, but Common Lisp is.  It is true
  for Java and C++ and lots of other "OO" languages that give you classes
  but do not give you objects all the way up that there can be objects that
  are not instances of classes and the very phraseology "instance of class"
  gives you away immediately.  In Common Lisp, we have type hierarchies and
  system classes, such that for any object, (typep <object> t) is trivially
  true and the function `class-of´ is defined on all objects.  (Please note
  that it is not a generic function.)

  Less premature judgment, more observation, please.

--
Erik Naggum, Oslo, Norway

However, after another brief sojurn to the HyperSpec I reremember the
fact about Common Lisp that was in the back of my mind when I drew the
distinction--while it's true that every object has a class, isn't it
the case that not all classes are created equal. It seems to me that
from a CLOS point of view (as distinct, perhaps, from a more-general
OO view) built-in classes are somewhat less useful than
standard-classes. To wit, I can't subclass them, I can't instantiate
them with make-instance the way I do all my user-defined classes, and
I can't change-class to or from them. But you knew that--anyway,
thanks for prompting me to go look it up.

-Peter

P.S. Have no fear: I labor under no delusion that Java (the language
I, sadly, spend most of my time thinking about) is really
object-oriented all the way down. At least in Java 1.5 (coming
whenever--I hope to not be programming Java by then) they're adding
automatic boxing/unboxing of the primitive types. But that's for
another newsgroup.

As far as I understand it this means that it is allowed for a conforming
Implementation to support subclassing of those classes specified as "System
Class" for example:

- package
- stream
- symbol
- number
- character
- array
- string
- sequence
- hash-table
...

This fact actually seems to be used extensively if you take a look at the
different CL implementations. Particularily the system classes stream,
character and string got extended in various ways. One example is the "Gray
Streams" facility which allows writing user-defined stream-classes. This
was done by subclassing stream with a class called fundamental-stream which
is then the superclass of the userdefined streams.

One could imagine something similar for system classes like sequence and
hash-table. The problem is that one has to provide a protocol in which all
functions using sequences or hash-table could get implemented. This would
be probably alot of work. In the case of hash-tables there are other
opportunities to make them extensible and some vendors already use them.

ciao,
Jochen

As you point out, there needs to be some protocol to integrate
user-defined things into system-defined things.

In the case of numbers, the various arithmetic operators (+, -, *, /
etc) are Generic Functions defined on the subclassable class <number>.

In the case of streams, there are operations such as read-element and
write-element that are Generic Functions defined on abstract streams.

In the case of sequences, there are the (compulsory)
forward-iteration-protocol() and (optional)
backward-iteration-protocol() Generic Functions which are used to
communicate between sequences and iteration/mapping functions/macros.  
The user can freely define new collection types and/or new iteration
constructs that work seamlessly with the built in things.

In the case of hash tables, there is the table-protocol Generic
Function, which returns the appropriate hash function and equality
predicate for the hash table.  Once again, the user can easily create
new types of hash tables which (in Gwydion Dylan at least) are exactly
as efficient as the built-in ones.

  Notice from the Food for Thought Department: You cannot /not/ use CLOS if
  you program in Common Lisp.  You can choose various different ways to
  deal with the type of your objects.  Some approaches are consonant with
  what other languages call "object-oriented" and some are not.  However,
  in languages that try to combine static typic and object-orientation,
  which is in fact theoretically unsound, you have to inform the system of
  the top-most class of every object.  If you do not declare the top-most
  class of an object in Common Lisp, it is always the system class named
  `t´, which is the supertype of all types.

  In many "OO" languages, especially those with dot notation, the methods
  are owned by the class, and you cannot access a method without compiler
  promises that the object it will call that method with is of a class that
  owns that method.  This is not object-orientation, it is just plain lunacy.

  There are two real approaches to object-orientation.  The first is known
  as message-passing.  You send an object a message and ask it to deal with
  it.  (This would not work with many people in this newsgroup.)  The
  meaning of the message is local to the object, which inherits it from the
  class of which it is an instance, which may inherit it from superclasses
  of that class.  In other words, you have no idea what happens when you
  send a message to an object, how many arguments it needs to be happy or
  anything.  (Much like many people in this newsgroup.)  This can get very
  messy, and it is therefore deemed appropriate to "clean up" this mess by
  adding compiler checks that that message on that object really takes that
  argument list.  This is the core mistake in the message-passing model.
  Smalltalk did not make this core mistake, which means that people from
  the non-OO-"OO"-language camps get all uneasy about Smalltalk.

  The second approach is generic functions.  A generic function has one
  definition of its semantics, its argument list, and is only /specialized/
  on particular types of arguments.  It can be specialized on any argument
  or any number of arguments in the argument list, on any type each.  If
  you think you do not specialize on an argument type, you have specialized
  on type `t´.  This fact comes into play when you want to find the most
  specialized method to call given a particular argument list and which
  method to call if it invokes `call-next-method´, etc.  You do not get to
  make the class implement methods on generic functions.  There is no way
  to add "method" definitions to a `defclass´.  There are, however, means
  to specify methods directly in the `defgeneric´.  Now, please note that
  `defgeneric´ defines a function that gets called with your arguments and
  then dispatches on those arguments to the methods.  The methods are /not/
  called directly, and neither are they actually defined directly.  If you
  do not define a generic function, one will be appointed to you.  Anything
  you say can and will be used against you, too, as you cannot do a lot of
  interesting things on the default generic function defined by `defmethod´,
  such as method combinations or funky argument lists.  You can only
  redefine a generic function with `defgeneric´, a fact that you should note
  right now before it comes back to bite you if you think you can load a
  file of updated `defmethod´ forms and expect it to run.  Documentation
  goes with the generic function, too.  See `defgeneric´ in the standard.

  What does this mean with respect to when you think you use OO?  In the
  message-passing paradigm, you need to define a class to get any methods
  at all and you have to use those methods on instances of that class.  In
  the generic function paradigm, you can define generic functions without
  ever defining any classes.  This tends to blow "OO" people's mind.

| I'd be interested to hear from experienced Lisp programmers about how
| *you* decide.

  The decision is often between a `typecase´ and a generic function and
  should in my view be made on pragmatic grounds.  There is no concept of
  the Right Class Hierarchy in Common Lisp.  There is nothing wrong with a
  regular function that does its own complex type dispatch.  The language
  does not become any less "OO" because of that.  The point with object-
  orientation of the /real/ persuasion is that objects have identity and
  with that identity comes state, but even that state information does not
  need to be "in" the object.  In primitive languages that pretend to be
  "OO", a "class" is not only a type identifier useful for type dispatch
  any way it seems convenient, it conflates the issues of generic functions
  /and/ data container.  That is just plain lunacy.

  In CLOS, if your class has distributed compoents, you can maintain a
  mapping outside the instance.  Slot access is via generic functions, too,
  so you can make a decision whether to compute or cache a value.  If you
  redefine a class to cache a value, you can decide whether to pre-compute
  the values or wait until it is actually used.  There are lots of things
  here that are just plain /convenient/ and that is where CLOS comes in.
  If you need the convenience, you use it.  OO in Common Lisp is not a
  religious good/evil issue, it is a pragmatic issue.  To people who think
  in good/evil terms, this is evil, as the good of OO can only be obtained
  through force and restrictions.  CLOS offers freedom.  It can be very
  hard to deal with freedom if what you were looking for in an OO system
  was a way to cage yourself in.

| Are there rules of thumb that you use such as (and these may be totally
| wrong, I'm just guessing what they might be given my limited experience):
| always start with classes and then "downgrade" to structs for performance
| reasons or vice versa, always start with structs and then "upgrade" as
| you require specific features of classes?

  It is not classes that experienced Common Lisp programmers start with.
  It is the generic functions.

| Or another way: given that I've spent most of my career programming in an
| an OO style, my inclination on first opening a new .lisp file is to to
| type "(defclass ...".  Is that a reasonable idiomatic Lisp approach or is
| that baggage from my past that I should try to shed.

  Shed it.  Also the idea that you were programming in an OO style.  There
  is no such thing.  You were only programming a particular object system.
  Now you get to program a different object system.

--
Erik Naggum, Oslo, Norway

As a pragmatic factor, the Lisp code you write with defstruct or a sequence
will be portable to more Lisps.  Many older Lisps do not have a full CLOS
implementation, but do have structures (or you can write the code to
implement them easily enough :-) and lists.

That being said, I've broken this rule and used a class more than a few
times when I could have used a struct or list (it's a bad habit from my
training as a Smalltalk programmer :-).  The good news is that I eventually
added functions that needed the use of defclass in these cases.    So it
goes...

In any case, most commercial Lisps have efficient enough CLOS
implementations that it shouldn't make a huge performance difference except
in inner loops.  So it's mainly a matter of taste.  I tend to like simpler
constructs and if you don't need inheritance, structs are simpler than
classes.

-Peter

  In my view and experience, the best OO design focuses on what you want to
  do, and the classes fall naturally out of the design.  If you start with
  the classes, the apparently strong desire to design the intrinsically
  perfect class hierarchy can ruin the entire project.  Encapsulation and
  methods are two orthogonal dimensions that are extremely hard to get
  right at the same time before you have some experience with how the
  design works.  That CLOS does not force you to encapsulate the methods
  with the types is a major aspect to my ability to "think design" directly
  in CLOS.  After the design has been worked out in this way, it can be
  documented and discussed and revised.  Some would call this prototyping,
  but that appears to me to be an unhealthy state of mind, the intent to
  throw it away is too clear.

--
Erik Naggum, Oslo, Norway