class, prototype, meta

jecel at lsi.usp.br jecel at lsi.usp.br
Sat Feb 28 20:25:24 UTC 1998


"Alan C. Kay" <alank at wdi.disney.com> wrote:
> 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 som
e point make a commitment to
> "kind" (I use this word because better terms like "type" and "class" have alre
ady been colonized with
> too-specific meanings in the computer world). So, while I think that you shoul
d be able to do absolutely
> anything with and to your programming system, I also think there should be "gu
ardians at the gates" when
> you go from one metalevel to another. E.g. it shouldn't be as easy to change t
he inheritance chain as it is to
> send a safe message to another object.

It is possible to change the inheritance graph with a simple message
in Self if you use "data parents". But nobody does this as the current
implementation can't deal very well with it, so performance suffers
considerably (besides, it hasn't been as useful as people would
thought it would be).

Other than that, changing objects and their inheritance structure is
pretty "heavyweight" compared to "safe" messages. You have to creeate
a mirror and navigate through it and so on. Of course, the programming
environment hides all this meta-level by allowing you to drag-n-drop
slots from object to object. But it still feels very different than
sending messages.

The problem with Self is that it hides its meta-level in the
implementation as much as possible. The notion of "kind" as
reified in C++ objects called maps is totally out of reach
of the Self programmer. Several applications suffer a lot from
this, like Ole Agesen's type inference stuff and Mario's
Smalltalk emulator. I love simplicity, but wouldn't trade
structured programming for GOTOs :-)

-- Jecel





More information about the Squeak-dev mailing list