[self-interest] Improvements to Self?

[Ian Woollard]

Jecel Assumpcao Jr wrote:
> Ian,
> 
> 
>>a) 'references'
>>
> 
> This is a cute idea which reminds me of the "value holders" ParcPlace 
> introduced into its GUI classes.
> 
> If you made the reference object point to its value using an assignable 
> parent slot, then you would have no problems sending references 
> messages that the value is actually supposed to execute. Of course, 
> then you have the "what is the value of self?" problem that is the 
> curse of any proxying scheme.
> 
> But how does sending the ":" message to the reference work (in theory, 
> not in the actual implementation which, as you say, can be optimized
> to be anything we like)? If it is some kind of slot, then we are back 
> where we started. If it is built in somehow then it makes more sense 
> but the language is still irregular since it needs a special case.

All languages need primitives. The point is to get the greatest
expressibility from the primitives.

> In case you missed my own silly proposal for this (which would also 
> handle your b): http://groups.yahoo.com/group/self-interest/message/1066
> 
> 
>>b) 'Allow optional parameters'
>>
> 
> While Self doesn't allow this, you can define a series of methods 
> manually to get a similar effect (this is used in quite a few places, 
> including the scheme to allow optional parameters to blocks). Where 
> this doesn't work too well is when there are too many combinations, 
> usually in initialization methods. Given that assignment slots return 
> the receiver, all of the following should work:
> 
>          button size: 40 at 10
> 
>          button font: f
> 
>          button color: bc
> 
>          (button size: 40 at 10) font: f
> 
>          (button color: bc) font: f
> 
>          ((button font: f) size: 40 at 10) color: bc
> 
> and so on. Of course, the needed parenthesis ruin it for scripting.

Yes. More like:

myNewButton: button new: Size: 40 at 10 Font: f Color: bc

It makes all the difference in readability.

>>c) No lexical scoping
>>
>>Methods instantiations should inherit off an assignable slot, that is
>>set to point to self.
>>
> 
> They do, though it is actually an argument slot named ":self*". Think 
> of argument slots as "assign once" data slots and it should be more or 
> less what you want.

I didn't know that! That's the way it SHOULD be! ;-)

>>Statements should inherit off method
>>instantiations. This simplifies the language, and regularises it.
>>
> 
> Blocks do that (through an invisible <lexicalParent*> slot). Statements 
> don't exist at the bytecode level, but earlier Selfs had "inner 
> methods" for representing nested expressions in parenthesis and they 
> also are set to inherit from the execution context.
> 
> Self didn't have lexical scoping until the latest release - Self 4.0 
> still faked it with inheritance.

That's odd. Why add lexical scoping?

OK. I clearly don't understand lexical scoping! What's the point of
it; how can it be better than inheritance?

>>d) Privacy
>>
>>Some mechanism is needed for this. The minimal implementation is a
>>slot that can only be accessed when called from a method found in a
>>slot of self; but that's a bit cumbersome to code with. (If that
>>sounds completely bizarre, don't worry, there are much better
>>implementations.)
>>
> 
> That implementation was used in Self 1 and 2. You would put a "_" in 
> front of a slot name to make it private or a "^" to make it public 
> (putting nothing at all also made it public). For data slots, you could 
> set the visibility of the corresponding assignment slot separately. 
> Normal message sends ignored private slots, but implicit self sends 
> would find them.

Not really the same thing. If I inherit off an object I have
access to the private slots. That's bad.

> This was dropped from the virtual machine in Self 3, but even in the 
> current user interface you can declare the visibility of slots (public 
> slots are shown in bold face, private ones in italics). It is simply 
> documentation now and has no effect on execution.
> 
> A more interesting scheme was created for the Us variant of Self 
> (http://citeseer.nj.nec.com/smith96simple.html) although the 
> programming environment would have to help automate the process 
> somewhat.

Hmm. Interesting. I'll check it out.

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

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