Random metaclasses for CL types

[Patrick Dussud <dussud@lucid.com>]

   Date: 23 May 89  1047 PDT
   From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

   [In reply to message from jonl@lucid.com sent Fri, 19 May 89 21:07:17 PDT.]

   I haven't been following this debate too closely, but on discussing
   it with Dussud and Jonl, I am not sure why the metaclass taxonomy cannot
   look like this:

		   class
		     |
	  ---------------------------------------------------
	  |               |                 |               |
   built-in-class basic-flavor-class structure-class standard-class
	  |               |
	  |     --------------------------------
	  |     |                              |
   flavor-implemented-built-in-class ordinary-flavor-class

   where basic-flavor has just enough structure to support the
   flavor-implemented builtins, and just enough ontology to represent flavors
   (as usual, I don't endorse these names). PATHNAME and STREAM are instances
   of flavor-implemented-built-in-class and user-defined or other flavors are
   instances of ordinary-flavor-class.

I think this would work. There are some issues that need to be ironed
out: Can the implementation allow subclasses of
flavor-implemented-built-in-class? If yes, then does 
flavor-implemented-built-in-class needs to expose its slots? or merely allow
subclasses to have slots and treat the superclasses like blackboxes?


   The other alternative is to flush built-in-class and let imlementations 
   decide their own metaclass hierarchy. Maybe that way we would see some
   implementors doing some innovative design.
I prefer this one, just because it leaves more options open to the
implementation. 

Patrick.