[self-interest] Improvements to Self?

Ian Woollard ian.woollard at tesco.net
Thu Aug 23 17:47:21 UTC 2001


Jecel Assumpcao Jr wrote:
> Better late than never, I suppose...
> 
> On Tuesday 14 August 2001 20:47, Ian Woollard wrote:
> 
>>>Indeed, I was just wondering what your ":" brought us that we
>>>didn't have with Self's "<-".
>>>
>>Several things-
>>
>>a) it can be used for privacy- by inheriting the handle object
>>appropriately you can add checking into the object so that it
>>only allows certain objects to talk to it.
>>
> 
> Right.
> 
> 
>>b) non builtin syntax can be added to the handle object like:
>>
>>c++.
>>c += 5.
>>
>>etc.
>>
>>Also, reference semantics are useful in their own right.
>>
> 
> Hmmmm... this seems to me like the opposite of a). Here you are 
> exposing things that would be better handled internally. Don't forget 
> that Alan Kay started OOP (sorry Simula fans!) because he felt 
> assignments were too low level to capture what was going on in the 
> computer.
> 
> 
>>Yeah. Its just sensible- I'd already worked it out I guess, I was
>>just confused by the way it was explained in the User Guide. In a
>>real sense Self doesn't HAVE lexical scoping; and doesn't need it-
>>it's all just syntactic sugar.
>>
> 
> True - the "contexts are cloned method objects" story feels much closer 
> to the dynamic scoping used in older Lisps. Most people can't tell the 
> difference, though this seems to be causing a lot of problems in newer 
> languages like Python.
> 
> 
>>>But sometimes that is exactly what you want to do. So you would
>>>need:
>>>
>>>  - public slots
>>>  - private inheritable slots
>>>  - totally private slots
>>>
>>Not clear why I would want private inheritable slots. Inheriting up
>>might be ok, but inheriting down; never. If I really want that then
>>I can add a separate public slot that can work out whether an object
>>is worthy of accessing the private slots.
>>
> 
> I am not sure what you mean by "up" and "down".
> 
> Is "up" when object A runs method X actually found in parent B and X 
> sends a self message Y that is a private method in A?

Uh. No that's down as the private method is found down the inheritance
to A. The private method bit is the one to keep your eye on. Inheritance
trees always go up to the root unlike wooden trees. This operation is 
calling down the inheritance tree. That's a safe operation in fact, as 
object A has the choice of whether X is its parent.

> And is "down" when object A runs local method X and sends a self 
> message Y that is a private method in parent B?

Uh. No, that's up. That's the dangerous one. Any evil object can make
any other object their parent, and hence access the private slots if the
language allows that; and it should not be allow it.

> Neither seems absolutely evil to me, though I would like control over 
> these situations.

I think we can assume that no object makes an object it doesn't trust
its parent.

>>>Otherwise any public method that called a private one would break
>>>when invoked by a child object that didn't reimplement the private
>>>one.
>>>
>>That could be allowed I think- only when 'self' contains the private
>>slot, and the sender was self is it allowed. Something like that.
>>
> 
> In my example 'self' didn't contain the private slot - its parent did. 
> It is a third case, not either down nor up from above (though it is 
> pretty close to "down").

Anyway, that operation is safe, because the method that accesses the
private slot is in the same object as the private one; so it should be
allowed.

Let me define the algorithm. First, it's probably necessary to define
my terms.

Theres: self
         receiver (the object being sent a new message)
         receive_slot_holder (the object that contains the slot).

Private slots should be accessed iff.:
        (self == receiver)
         and (receive_slot_holder == self)

The first part says that only the object can access a private
slot inherited from itself. (No fiddling with friends private parts
as Bjarne Stroustrup puts it.)

The second says that the private slot must be not inherited off of, but
instead be part of the object itself. That stops children fiddling with
parents privates.

Anyway I think I've got this straight/comments welcome.

> -- Jecel
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
> 
> 
> 



-- 
- Ian Woollard (ian.woollard at tesco.net)

"Is a planetary surface the right place for an expanding technological 
civilization?"
- Gerard O'Neill




More information about the Self-interest mailing list