privacy and brevity (was: Improvements to Self?)

[Jecel Assumpcao Jr]

On Thursday 23 August 2001 13:47, Ian Woollard wrote:
> [up and down, the real story]

Ok. While the arrow goes from the object to its parent, I like to draw 
the tree with the parent higher up.

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

Agreed.

> 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.)

This is what Self 1 and 2 had. Actually, I think that if an object sent 
a message to itself with a normal message send ("self someMess") 
instead of with an implicit self message (just "someMess") then it 
would not see the private slots. But this is not the kind of detail 
that anyone is likely to notice.

> 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.

Self never had this, but an interesting way could be to allow local 
methods for method objects. Something like

        ....
       myMethod = ( | x <- 0. localMeth: z = (x+z) | ....  ).
       ...

This is sort of like a named block. There would be an advantage over a 
regular block if localMeth: was used several times inside myMethod. Now 
lets move this to some parent object:

      ...
      myMethod = ( | x <- 0.
                               private* = ( | localMeth: z = (x+z) | ) |
                               .... ).
      ....

Should work just like before. But if we could share this private object 
with other methods in this object, the this set of methods could invoke 
localMeth: but nobody from the outside (including children) could.

This can't be done textually without putting the private object in some 
globally known place (which would defeat the purpose, of couse!) but 
this could be built in the graphical environment. All we need to do is 
modify the VM to support it ;-)

I just tried it and the graphical environment prints the above method 
as "( | x <- 0. private* = 0 _AsObject | ...". So it was easy to create 
a second method with the same private parent. It doesn't run because 
the parent of the localMeth: is the receiver of myMethod and not the 
current context like it would have been with a block (Self is ignoring 
our attempt at "nesting"). So localMeth: doesn't find "x".

> It's important to expose the right things. If I want to pass an
> objects variables to an editor for editing then I should be allowed
> to. I should not have to jump through hoops to give something that
> the language can give; I've had to jump the hoops in Java- no
> references (lvalues in C speak) are a serious restriction in the
> expressibility of the language. There are ways; but they are not
> good; I've found.

Well, there is "domain level programming" and then there is "meta 
programming". You should have to jump through some hoops to switch from 
one to the other, otherwise the danger of getting them mixed up is too 
great.

> Elegance of code is important.
>
> how would you do:
>
> newIntegerBrowser: &myIntSlot.
>
> in Self?

This would work if there is such a thing as an "integer slot browser":

                newIntegerBrowser: (reflect: self) at: 'myIntSlot'

I would hate to see something like this in a "regular" application.
-- Jecel