At 11:33 PM -0400 2/27/98, David Farber wrote:

i really like the idea of adding prototypes to squeak, but is there a way to add prototypes *and* keep classes?

what i would like to see is a meta object protocol that had the flexibility to facilitate both modes of "sharing" (to put it terms of the Treaty of Orlando).

could we pull something like this off? you guys at Disney have hinted about changes to the meta model; have you thought about anything like this?

dave

--------------

Yay Dave...

Here are a few thoughts about prototypes. The first point, which you hint at, is that classes and prototypes are not necessarily distinct. In fact one of our "three inspirations" -- Sketchpad -- had classes (they were called "masters") that were prototypes. This was a hot topic for discussion in our group at PARC during much of the 70s. To sum up: we thought that classes should be able to act as prototypical objects (or should at least have several prototypical instances as examples of typically instantiated objects of the class). We still liked the idea of "class" not so much for pragmatic reasons, but for reasons of design and abstraction.

Here are some of my longstanding prejudices about this. We want children (and all programmers) to be able to mess around, to do the equivalent of sketching where you find the exact line you want from a whole mess of lines you've made. You darken it and find a way to extract it, or to disappear the rest. This argues for a bottom up approach, and for something like prototypes. When you have made something that seems typical of what you were trying to make, you should be able to indicate which parts are specific and which general, and then use it to make more. This argues for "classes" or "typeness". One of the ways Adele and I did this with the kids was to give them "suggestive objects" (like "Joe the box" -- described in various articles including SciAm Sept '77), have them play with the objects, and then add to them. What was already there in the suggestive object provided examples and analogies for the (sometimes very adventurous and clever) modifications and additions that the kids programmed. This was a bottom up approach that let the kids "build outwards". We also found it important to gradually teach the kids to design. We did this by giving them a way to capture the essences of the situations they were trying to model. These abstractions were arrived at bottom-up, but then allowed the kids to easily make the classes that were suggested.

But I think a critical point here is that just being able to clone willy-nilly is confusing one metalevel with another -- and here is where I disagree with the "Lieberman" and SELF (what I think of as the LISP, or "data structure") schools of prototypes. I feel it is very important to at some point make a commitment to "kind" (I use this word because better terms like "type" and "class" have already been colonized with too-specific meanings in the computer world). So, while I think that you should be able to do absolutely anything with and to your programming system, I also think there should be "guardians at the gates" when you go from one metalevel to another. E.g. it shouldn't be as easy to change the inheritance chain as it is to send a safe message to another object. An analogy is that one of the reasons we put in encapsulation and tried to get rid of data structures is because an assignment statement is a different metalevel than a function call, and you just should not be able to do either equally easily. Our initial idea was to at least confine the dangerous assignments while we were learning how not to need them. Obviously, allowing the equivalent of easy assignments to deep structural elements (like inheritance pointers, etc.) is a worse idea. The first Smalltalks also allowed "no overhead" syntax definitions -- it was an integral part of programming. This gave us an easily extensible language on all fronts of syntax, semantics and pragmatics, but turned out to be a bad idea for the same reasons. In Smalltalk-76 we perhaps reacted too much in the opposite direction, and didn't put a more appropriate meta-level in the language for defining syntax -- but the earler way we worked simply led to a tower of Babel. But it is really terrible if you just ban such things. That is too moralistic and smacks of the Wirth school of (non)programming. This is why well thought out metasystems should allow the good designer/programmer to have their cake and eat it too. The "Metaobject protocol" by Greg and Danny, et. al., at PARC is an inspiring further advance in what we had done there in the '70s, and it gives some tantalizing insights into what could yet be invented....

One of the reasons we built Squeak the way we did was to be able to quickly arrive at a basis for making a further qualitative improvement to programming systems. Squeak isn't it, but it has all of the tools to make its successor. One of the ways to do this is with a well thought out metasystem, and that goal is woven into much of our current thinking and working.

Cheers,

Alan