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 toget 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.
okay, i am trying to keep up here. how is an assignment on a different metalevel than a function call. since you made the assertion, i can certainly see where you are headed, but what is critera for a metalevel?
But it is really terrible if you just ban such things. That is toomoralistic 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....
you mentioned this book in your oopsla keynote, but i haven't been able to get my hands on it. to be honest, i haven't tried that hard to get it because you remarked that it was probably only comprehensible to someone with an extensive Lisp back ground (which ain't me) and it really needed to be rewritten for Object Land at large (for which, i believe, you offered a second Smalltalk balloon like the one you gave Dan). so, since *you* read it and seemed to get a lot out of it, why don't you clue the rest of us in on some of its more salient points and how you think we might be able to translate them in squeak (or the next blue thang).
thanks, dave
-- j. david farber oo architect+mentor numenor labs incorporated in sunny boulder colorado dfarber@numenor.com www.numenor.com