On Tuesday, August 20, 2002, at 10:06  Uhr, Alan Kay wrote:

> First, I should say that I really like (a) a lot of the ideas in Self, 
> and (b) the motivation behind trying to do Self.

Same here.  I do have a feeling that the direction, while very 
fruitful, turned out to be "too uniform", in some senses.  There is no 
fence at all to the meta-level at one point ( object vs. class ) and 
still a big one at another ( object vs. code/method ).

>      But, I think there is an entity somewhere between classes and 
> Self prototypes

Yes, that is what I have so far as well:  the "class equivalents" are 
somewhere between what we call classes and objects/prototypes, and the 
"object equivalents" are somewhere between objects and method contexts.

> (I've been calling them exemplars)

I like to call them "parametrized objects".

>  and some action somewhere between instantiation and cloning that 
> would work better

I am still swimming a bit on that one.  There is plain "invocation", 
supplying the required arguments and getting a result.  But what is the 
result?  Either (a) "p-object + params" or (b) "result of some message 
sent to p-object + params".

Answer (a) is closer to normal instance creation, (b) is closer to 
method invocation.

Then there is currying, which is "p-object + some params", clearly a 
variant of (a).  Interestingly enough, this would be considered a 
refinement step similar to subclassing, but it could also be considered 
partial instantiation.

Existing method invocation is a special case of (b):  the method is a 
parametrized object, the method-context holds the parameters, it is 
then sent the "value" message.  This definition is, of course, 
recursive, but that doesn't bother us, we just cut the recursion off at 
the primitive level.


>> 5) removing inheritance from the base-level
>>
>> parent slots are a neat language design "pun" (a single thing is used
>> for both "has-part" and "inherits-from" relations) but it would be
>> better to have all program structuring stuff live exclusively in the
>> meta-level.
>
> Precisely. The problem with parent slots is that they are much too 
> lisp-like for an OOP language. Also, there are many other 
> relationships that are useful (as in CYCL) that should be metalevel 
> implementable.
>
>> Squeak doesn't have parent slots, of course, but does have
>> #class, #isKindOf: and other unmarked portals into the meta-level
>> underworld.
>
> We need a complete (or darn close) and real metasystem.

How do we know when we have a complete metasystem?  There are too many 
different directions in wich we can abstract.  Anyway, the only 
credible candidate I've seen so far is the research done in software 
architecture.  They start off with "components" and "connectors", and 
then refine from there.

[..]

>> The "separation of concerns" step-by-step development is the way to go
>> in the pink plane. But what is the best style for Squeak on the blue
>> plane?
>
> One way to think about this is that you want everything to be 
> separate, but to be easily able to specify dynamic relationships that 
> express the nonlinearities. For example, "a really good thing to do" 
> in Squeak would be to put a vertical line in a method and have a 
> really simple semantic description on the left, and an optional 
> case-based set of optimizations on the right. Run both to test, etc. 
> The case pattern matches constitute the dynamic relationships that 
> "join" the two kinds of descriptions. Similar techniques can be used 
> to implement multiple perspectives, delegation models, and nonlinear 
> event-driven interactions. The whole blueplane idea here is to try to 
> separate strategies from tactics and "ors" from "ands", but to be able 
> to relate them in a clean way when it really helps matters.

Hmm...

Marcel