Re: To CLOS or not to CLOS?

I understand Graham's reluctance.  I, too, was quite reluctant to accept CLOS.
At first, the problem was that CLOS was just one of many competing object
systems that were proposed for Common Lisp.  LMI favored Drescher's Object
Lisp, and of course had Flavors.  The second problem is that CLOS has a *lot*
of bells and whistles.  It was unclear to me what the purposes were other than
to have a lot of bells and whistles.  The third problem is that CLOS is quite
verbose.  CLOS just seemed to me like a *big* ball of
indistinguishable `object-stuff'
that could have just as easily been done with simpler mechanisms.

That changed when I started to use CLOS (under protest) on a big project.  I
realized that the interface to CLOS is actually quite simple.  The
verbosity occurs
because CLOS concentrates the options in a single place and allows for
customization and dynamic changes at nearly every part of the system.  The
extreme bells and whistles are there to allow advanced users to create
easy-to-use
and easy-to-modify systems for less experienced users.

There were two particular moments when I grasped what I had missed before:
The first came when I had to change a slot into a computed value, but
I discovered
that there were legacy persistent objects in an existing database that still had
values in the slot.  It wasn't possible to rename the slot itself, but
it was trivial to
rename the accessors.  It was clear that the disconnect between slot-names and
accessors was *intended* to solve this sort of problem, and that the verbosity I
hated before had saved my butt on a particularly thorny problem.  I
was impressed.

The second moment came when I had re-factored a class into a
superclass/subclass relationship.  I then reloaded the file and tested
the software
to see that it worked ok.  It did.

Then I thought about that.  I just re-organized the class topology on
the fly in a
running system.  How on earth could that just work?  Obviously
existing instances
had to be converted on the fly to new objects and any dependencies had to be
recomputed.  But a huge chunk of CLOS that I had thought `overkill' was what had
stepped in and made sure that I could just reload a file and keep
going.  Once again
I was deeply impressed.

I think if Graham spent a good chunk of time working on a CLOS project
that he, too, would come around to the point of view that CLOS is a
significant achievement.

On 2/19/07, [email protected] <[email protected]> wrote:
> > On Sun, 2007-02-18 at 18:22 -0600, Paul F. Dietz wrote:
> > Over the past couple years, I have really learned to appreciate CLOS...
>
>    Paul Graham mentioned at one point that after years of LISP
> programming he never *once* used CLOS to get the job done.  Perhaps
> because LISP's pre-OO parts are so powerful you can do a lot already
> without resorting to objects.  But obviously CLOS has it's fans as
> well.  If you are a Common LISP user, what do you like or not like
> about CLOS?  For example, is the generic function approach the best
> way to do OO, or does it have some drawbacks compared to the common
> object-dispatched system?
>
>
>


-- 
~jrm