Simpler Self RFC

[Josh Flowers]

>Message: 2
>   Date: Tue, 6 Aug 2002 18:51:08 -0300
>   From: Jecel Assumpcao Jr <jecel at merlintec.com>
>Subject: Re: Simpler Self RFC
>
>Josh,
>
>thank you for your comments!
>
>> 1. simpler method/block story
>> I don't know enough about how self currently works to properly
>> comment.  Are there any cons to this change?
>
>Yes, the current complicated scheme (five different objects) is needed 
>to get different behaviors in different situations. With my 
>simplification you would have objects answering messages they aren't 
>supposed to answer. Of course, you aren't supposed to send them these 
>messages, right? So the practical result is that sometimes you will get 
>a hard to find error where now you get a "message not understood".
>
>> 2. simpler non local return
>> Wouldn't this require that all objects have a default slot (^)? 
>
>All activation objects would need such a slot (and methods and blocks 
>when combined with proposal 1, which is needed for this to work). 
>Normal objects wouldn't have this slot.
>

Of course, that makes sense now.

>> From
>> what I can tell an object in self does not normally contain any slots
>> by default.  Am I wrong about this?
>
>The empty object, ( ), has no slots at all. It can receive a set of 
>primitive messages even so, which is a bit disturbing to some of us.
>
>> 5. removing inheritance from the base-level
>> I'm not sure what you gain from this one.  Personally I'd probably
>> leave it out.
>
>I am also not sure about this one and the assignment one (4) either. 
>This can even be considered a complication instead of simplification. 
>Parent slots were Alan Kay's main objection to Self and that got me 
>thinking about them.
>

Did he have any specific objections to parent slots?

I find them a bit odd myself, but I think it's more because they're named 'parent slots' then because of how they're implemented.  Unlike parents in a class based language they cannot contain data that should be shared between their children, only behavior.  This makes their usage feel strange when your more accustomed to a classic OO language.  I'm not sure Self's inheritence is a bad thing (I know it's been stated that inheritance is actually harmfull because it breaks encapsulation), but it does seem odd at first.

Maybe name them behaviour slots, or delegate slots (although they do more then just delegate messages)?  It also seems like there are a couple of different uses for these special slots - 

1) simple message forwarding - your simply sending the message to another object i.e a parent reference to globals.

2) behavior sharing - not only do you need to forward the message to another object, but that object needs to reference the object that is forwarding the message (as 'self' none the less).

3) inheritance - everything that #2 does, plus copying the "child" object must also cause the parent to be copied.  As far as I know this doesn't exist in Self, but I haven't looked into it.

Of course I haven't used Self that much, and these comments are somewhat off the cuff, so I may be speaking in error.

josh