What are we up to?

[Steven <Handerson@CMU-CS-C.ARPA>]

There seems to be a general lack of attention to the tradeoffs of various
systems.  It sounds like T- or LOOPS- like things that do things at runtime are
generally slower than things like Flavors, since Flavors tries to do all it can
at compile time.  Also, instance variable references in Flavors are an
indirection through a mapping table; probably faster than a hashtable
reference.  Hence Flavors is preferable for low-level system programming and
apparently for all manner of hackish things, whereas higher-level programmers
probably need LOOPS or something to maintain their sanity.  Then again it's
possible that the overhead is deemed negligible, and we might as well do stuff
at runtime.  I'm not sure.

Also, the syntax of Flavors (etc.) reflects the semantics.  Since we don't want
to often change what are and aren't instance variables (so that we CAN do
things at compile time), the instance variables are made to look like normal
variables.  It's also been decided it would be neat if they acted like lexical
variables, and can be closed over.

I think it's obvious that there should be at least two major object systems;
one that does stuff at runtime (and is therefore more flexible) and another
that does stuff at compile time (and is therefore more efficient).
Furthermore, I think making an object system is more of an art than a science,
for the same reason that mathematics is; they're intellectual tools.  I
wouldn't want to force someone to use my tools, but I don't think I should be
forced to use Flavors all the time either.  I propose that we have a kernel
that supports diverse object systems, but that we continue trying to develop a
good standard (set of) systems.

RUNTIME OBJECT SYSTEM

The ability to trade off instance-variable vs. message should be user-visible,
not part of the compiler or object system.  Active values can use this.  You
can do this by remembering method code and recompiling anything referring to
that instance variable, but I'd rather there be a primitive that did it, even
if it cost some time.  This would allow methods to close over lexical variables
without making the closure-handling code worse, besides improving user response
time.

KERNELS

My kernel could be expanded to support runtime systems by adding "methods" that
would set and get an instance variable (without having to call a function).
Everything could send a message, and some messages would be (fairly) quickly
converted to instance-variable references, without the need to recompile
anything.  This would also speed up accessing instance variables of other
objects.

The object system would have to standardize the names of the messages; I'd
suggest just the iv name and the iv name prepended with SET-, interned in the
same package.

METHOD COMBINATION

My current impression is that everything regarding multiple inheritance is a
kludge, and you can't justify one kludge as compared with another except in
terms of efficiency or ease of use.  In the first, Flavors wins, and the second
depends upon who you ask.  You seem to be ignoring the fact that, although just
as POWERFUL, method-combination is "automatic" - the system, not the
programmer, writes the code.  I think it's currently done wrong, but somebody
might figure out some better way.

If we assume the best, when we combine types an artificially intelligent
machine goes and figures out what order etc. to call the methods in.  This may
take a while, and is best done at compile-time.  If you don't like that, how
about something that asks the programmer how to solve conflicts?  You want to
do that at runtime?

ENDING PLEA

Would someone please give me a reference (net address, anything) to find out
more about T's object system?  A manual would be nice.