blue ideas
Marcel Weiher
marcel at metaobject.com
Mon Aug 26 12:53:04 UTC 2002
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
More information about the Squeak-dev
mailing list
|