Hi. I'm writing a short review of the 1988 paper, "The common Lisp
object system metaobject kernel: a status report", by Daniel G. Bobrow
and Gregor Kiczales.
One of the things that I'm noticing is that it's easy to find other
papers where people exploit the MOP to get CLOS to do something
unusual, e.g., PCLOS extended CLOS to get persistent objects using a
relational database almost transparently behind the scenes.
It's not so easy to get a feel for the how CLOS is most commonly used.
I'm not even sure there's a good answer for that, since if you were
doing something common, you might not need as much power as CLOS
provides.
Anyway, if there are any lispers out there willing to summarize how
they use CLOS, I'd love to hear it. I'd also like to hear from anyone
who feels like they have a good idea of how people are using CLOS
these days and how CLOS use has evolved since it appeared.
--
--Ed L Cashin | PGP public key:
·······@uga.edu | http://noserose.net/e/pgp/
Ed L Cashin wrote:
> It's not so easy to get a feel for the how CLOS is most commonly used.
Puzzled: For OO? Too simple? But that's the answer. Are you asking, how,
when, where, why is OO used? Because the answer is, if you like OO, all
the time. Graham and Gabriel hate it, but what do they know? The world
outside computers has classes. Computer languages should have them, too.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Generic Functions are the most important part of CLOS for me. I even
use them in languages that don't have them! (;-) ...as long as there's
closures or "inner classes"...) GFs allow me to write modular
compositional platforms. See the Xerox PARC stuff on "Open
Implementation"
(http://www2.parc.com/csl/groups/sda/projects/oi/default.html). My
applications have been in the management of content and metadata for the
Web.
For clues on how these ideas have evolved (or devolved!), there might be
something to be gained from comparing the Open Implementation stuff with
the later Java-based "Aspect Oriented Programming" stuff. (I haven't
actually looked into AOP myself. Anybody?)
Ed L Cashin wrote:
> Hi. I'm writing a short review of the 1988 paper, "The common Lisp
> object system metaobject kernel: a status report", by Daniel G. Bobrow
> and Gregor Kiczales.
>
> One of the things that I'm noticing is that it's easy to find other
> papers where people exploit the MOP to get CLOS to do something
> unusual, e.g., PCLOS extended CLOS to get persistent objects using a
> relational database almost transparently behind the scenes.
>
> It's not so easy to get a feel for the how CLOS is most commonly used.
> I'm not even sure there's a good answer for that, since if you were
> doing something common, you might not need as much power as CLOS
> provides.
>
> Anyway, if there are any lispers out there willing to summarize how
> they use CLOS, I'd love to hear it. I'd also like to hear from anyone
> who feels like they have a good idea of how people are using CLOS
> these days and how CLOS use has evolved since it appeared.
>
Ed L Cashin <·······@uga.edu> writes:
> Anyway, if there are any lispers out there willing to summarize how
> they use CLOS, I'd love to hear it. I'd also like to hear from anyone
> who feels like they have a good idea of how people are using CLOS
> these days and how CLOS use has evolved since it appeared.
I try not to draw the lines too specifically between what is part of
CLOS, what is part of the MOP, etc. I tend to think in terms of
standard uses of CLOS, and some more advanced uses.
At the Lisp conference, there were several large systems that were
developed using macros, in places where others might imagine
CLOS/MOP-based solutions being a natural fit. At least I prefer it if
details are hidden from me; if I don't have to dive into new macros --
effectively new terminology, in order to make use of a system. In this
sense, there have definately been some interesting uses of CLOS
features. One of them is the DBC stuff:
http://groups.google.com/groups?q=dbc+group:comp.lang.lisp&hl=en&lr=&ie=UTF-8&selm=864stbopva.fsf%40gauss.muc.de&rnum=1
I thought it was nice to see how someone could augment the existing
semantics incrementally to add the desired features. Back when I was in
college, there was a class taught in a language called Clue that had
such contract features. Some of the people who used it loved it, as
always there are folks to get wedded to certain ideologies. CL is a
good language to at least try some of these concepts out, whereas many
academic CS people go through great pains in creating whole new
languages from scratch to do such things.
In a somewhat similar way, we (Portus) exploited certain CLOS features
to handle asynchronous programming, both directly and indirectly.
Directly, we used CLOS's gf's, multi-methods, etc. (the usual stuff).
But indirectly, we borrowed certain idioms from CLOS and applied them to
our software. For example, we have our own concept of processors, and
use (next-processor-p) and (call-next-processor).
dave
Ed L Cashin <·······@uga.edu> writes:
> It's not so easy to get a feel for the how CLOS is most commonly used.
Not from simply observing the documentation of CLOS. You have to use
it to get it.
> I'm not even sure there's a good answer for that, since if you were
> doing something common, you might not need as much power as CLOS
> provides.
You shouldn't ever being doing something common. Lisp is the ideal
vehicle for programming when you don't know what it is you are doing.
CLOS extends that paradigm. Look at the responses people have written
to this question. They talk about doing things `incrementally'.
I.e., about writing the code without a codified and canonical
blueprint. ``Should object FOO be an instance of a special class, or
is it just a variant of this other class? I dunno, but I *do* know it
had better be acceptable as the first argument to the PAINT
function.... oops. That slot in FOO and the one with the similar
name in BAR really ought to be a MIXIN... Oh, wait. BAR ought to
inherit from FOO, not the other way around....''
To support this kind of experimental, incremental programming, you
need the full power of CLOS.
As an example of MOP usage, the other day I wanted to create a class
hierarchy for some foreign data. There was some documentation
concerning what the foreign data was supposed to represent, and I
could have written DEFCLASS statements to reflect the documented
hierarchy. Each foreign object had a pointer to a structure that
represented the foreign type, so rather than build a class hierarchy
statically based on the documentation, I built the CLOS class
hierarchy dynamically based on the runtime foreign type data. (And as
it turned out, the documentation was in error in parts, but the CLOS
structures represented reality rather than the documentation.) What
if they change the foreign class hierarchy in the next release? It
doesn't matter to me, I can track the changes programmatically.
On 23 Nov 2002 18:38:48 -0500, Ed L Cashin <·······@uga.edu> wrote:
> Anyway, if there are any lispers out there willing to summarize how
> they use CLOS, I'd love to hear it. I'd also like to hear from anyone
McCLIM uses CLOS--and the MOP--to implement CLIM.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
On 23 Nov 2002 18:38:48 -0500, Ed L Cashin <·······@uga.edu> wrote:
> Anyway, if there are any lispers out there willing to summarize how
> they use CLOS, I'd love to hear it. I'd also like to hear from anyone
LISA also uses the MOP:
http://lisa.sourceforge.net
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README