Re: tiny-clos-questions

[Ken Anderson <kanderso@bbn.com>]

At 11:39 AM 11/7/98 +0100, Klaus Schilling wrote:
>Craig Brozefsky writes:
> > MAILER-DAEMON@cx606007-a.irvn1.occa.home.com writes:
> > 
> > How many people are using tiny-clos?  I grabbed the 1.7 version which
> > came witha  copy of stklos I had DLed awhile ago, and have wrapped
> > that up as a module and am dinking around with it.  I prefer a generic
> > function based OO system myself, so I'm pretty happy with it.
>
>Tinyclos is too clumsy for tasks that don't require a meta object protocol.
>Thus I use a lightweight object system like BOS. Boekemeier wouldn't call it
>an object system, though.

TinyCLOS may seem clumsy, but the meta object protocol is a good thing.
Tiny is a sketch, a very elegant sketch, of how to do a MOP based object
system.

It is too tiny in many ways, but it is straight forward to make it useful.
For example, every object in tiny is opague, in the Scheme tradition.  This
makes debugging extremely painful.  A solution is to give metaobjects names,
like most object systems do.  Also, method lookup is done from scratch for
each generic function invocation.  But, method lookup can be memoized.

STK is a great example of the power of tiny clos.  TK objects have a
different metaclass, but look just like other STK objects.  Extending this
idea for guile, i could imagine a MOP that unified things like foreign
function interface, and remote method invocation.

The optimization STK uses, last time i checked, was to write tiny clos in
C, so memoization wins are still possible.  

Common Lisp has extensive optimizations for objects of "the standard
metaclass" but, i'd recommend a balanced approach that provided reasonable
performance for all metaclasses.  When guile gets good, maybe the
metaobject stuff can be moved to compile time.