Alan Kay wrote:
>      I think that the Self way is pretty good and clean, since it extends
> referential transparency one more level. A little more of a metadescription
> would make things even nicer and more useful ...

The traditional implementation of Self has (among other things)
a name, some flags and a value for each slot. The flags distinguish
among the four kinds of slots like this:

   switch ( slot.flags & TYPE_BITS ) {
       case CONSTANT  :
                        returnToCaller ( slot.value );
                        break;
       case DATA      :
                        returnToCaller ( receiver [ slot.value ] );
                        break;
       case ASSIGNMENT:
                        receiver [ slot.value ] = getArgFromStack();
                        returnToCaller ( receiver );
                        break;
       case METHOD    :
                        callInSelf ( nativeCodeCacheFind(slot.value) );
                        break;
   }

While Self's system takes care of the 95% of the accessor methods
that are trivial, non trivial ones require you to define and
extra, "hidden" slot into which you store the actual value (for
example, you have the non trivial #color and #color: slots that
use the simple #rawColor and #rawColor slots). Thinking about this,
I created a Self implementation which replaced the flags field
with a pointer to native code, so the above fragment would now be:

    callInSelf ( slot.nativeCode, slot.value );

For the CONSTANT, DATA and ASSIGNMENT slots, the nativeCode just
does what the original fragment did with the value. For the
METHOD slot, the nativeCode originally looks up value in the
cache, but then it overwrites the nativeCode field with the result
so this step is skipped the next time.

Now the whole idea was that the user would be free to create
new types for slots (in Self and then compiled to native code)
as a possible alternative to the #rawColor thing. I now feel
that this was going to far.

-- Jecel