[self-interest] Improvements to Self?
Jecel Assumpcao Jr
jecel at merlintec.com
Thu Aug 9 21:38:25 UTC 2001
> 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
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
More information about the Self-interest