From: "E. Dean Tribble" <tribble@netcom.com>
Replying To: Chip Morningstar <chip@communities.com>
Date: Tue, 20 Oct 1998 09:48:48 -0700 (PDT)
Subject: Re: Types, Makers, and Inheritanc

I shan't make many comments, but some things I can't resist.  I hope my 
comments are not too terse....

> Tyler sez:
> >[#] I would like to propose a new design heuristic. Anything that causes Ping
> >to make a diagram is too complex and must be simplified.
> 
> [+] I think this is a fine heuristic, as long as our benchmark is Ping and
> not MarkM. MarkM will make a diagram for anything :-)

[-] While there's some truth to this :-) it would be a shame to limit oneself to
things which don't require diagrams (particularly when the diagram is cool). 
The particular topic described here is the "knot at the top of the world" in
Smalltalk speak, and is complicated primarily because E has the "metabraid" 
(types, makers, classes, class-loaders, etc.) accessible in the language. 

> >[] I would like the type object and maker object to be identical (ie: no
> >separate type object). I will also reiterate my desire to eliminate
> >inheritance.
> 
> [+] I agree. While the separation of type and maker has a certain
> conceptual elegance, this does not IMHO come near to offsetting the
> additional cognitive and notational overhead of having yet another
> abstraction to keep track of, explain, code, etc.

[-] Rule #1 of Capability-based Design:  Distinctions in authority are 
represented with distinct objects.  Programs must be able to manipulate 
descriptions of objects and their protocols (i.e., type objects) without 
granting the authority to create instances.  It's useful to be able to 
talk about the protocol of bank accounts, create user interfaces to them, 
etc. without allowing the construction of them outside of banks.  This 
means that they must be separate objects.