[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bobrow's message, Snyder's message, Flavors kernel



My immediate reaction to Bobrow's message is that I'd like to keep Lisp:send
simple, and in particular not have it look like an object system (his looks
like LOOPS).  Remember that LOOPS's sending function can resend
MessageNotUnderstood to the object if it wants (etc.).

I'd prefer, for sending to lisp types, a way to select a function based on the
lisp type, which would be separate from lisp:send.  You'd do (if (instancep x)
(lisp:send x 'foo) (lisp-send x handler-object 'foo)), maybe as a macro.  I
suppose lisp:send could do this automatically if it took a handler-object, but
you might want to send to an instance and treat it like a lisp type (isn't this
great?  Yum).  Basically the handler-object acts as the "type-type" or object
system of the lisp object, so that a cons interpreted as a Flavor can act
differently from a cons interpreted as a LOOPS object.  I think this is
important, but maybe somebody else could explain why.  Somebody who knows
something about the type system can design this.

My immediate reaction to Snyder's message is that object systems (especially
the part doing inheritance) are programs written in Common Lisp, and so if you
want to supply a real object-oriented programming *environment*, you're
basically reinventing the wheel.  Yeah, maybe it's time to reexamine the
existing systems, but if we provide the necessary hooks to implement object
systems, we don't need to rush into anything.  People can use Flavors in the
present form if they can stand it.

Standardizing on some unproven system might be a mistake. I think Flavors has
survived in its present form for the same reason that Fortran (which CL hopes
to replace) has survived (cost of rewriting, people getting used to it), and we
could easily make some similar mistake with another bogus system, although I
doubt we'd come up with anything as hairy.  I feel sort of bad for propogating
a system like Flavors, but I think some of the basic concepts (NOT inheritance)
might be worth something.

Hence, my kernel tries to capture the ESSENCE of Flavors without the specifics
of inheritance, and packages the non-portable aspects of mapping tables and 
instance variables.  Anybody who's serious about this can look in
[CMU-CS-C]<HANDERSON.PUBLIC>FLAVORS-KERNEL.TXT.  Please address all specific
comments and suggestions to me, and I'll get back to you (probably next year).