"E. Dean Tribble" <email@example.com>
Replying To: Chip Morningstar <firstname.lastname@example.org>
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.