[self-interest] Improvements to Self?

Jecel Assumpcao Jr jecel at merlintec.com
Thu Aug 9 21:38:25 UTC 2001


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.

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.

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

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

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

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



More information about the Self-interest mailing list