Re: slot types

[markl@glyphic.com (Mark Lentczner)]

(Time to jump into the fray...  Sorry this is so long!)

WELL, slot-types are an issue near and dear to my heart.  Here is what we
do in Glyphic Script(*) (whose object model is close enough to Self's for
this to be relevant):

Slots can be one of three types: Copied, Global, or Private.

Copied are equivelent to instance variables.  Every time you instantiate an
object, the instance gets its own copy of the slot.  Furthermore, the
standard library sets each of these slots to copy of the object in the
corresponding slot in the parent.  (The object copying is under programmer
control and is NOT part of the object virtual machine).  If you add a
Copied slot to an object, then try to store into that slot in a previously
existing instance of the object, the slot is "copied down" into the
instance by the virtual machine before the store.

Global slots are like class variables.  There is only one of them, and all
instances of an object reference the inherited slot.

Private slots are private to a given objects.  The lookup mechanism will
only see them in messages sent directly to the object that has them, and
not when messages are sent to instances.  This is useful for two reasons:
it lets methods store auxillary data in slots w/o worrying about name space
collision, and it solves the famous "how do you give a name to this object
without it becoming the name of all instances" problem.  Ex.:

    a is an object that inherits from Object and has a private
      slot "name" with value "widget"
    b is an object that inherits from a and has no slot "name"

    a.name -> "widget"  -- lookup finds "name" in a
    b.name -> "a widget"  -- lookup skips "name" in a, and finds it in Object
                          -- which synthesizes a name based on the name of
                          -- b's parent

We used to have no slot types, but evolved these over the last three years.
Private was a big boon, as was the copy-down on store aspect of Copied
slots.



There is another aspect of Slot Types that hasn't been discussed here
before: execution semantics.

Self, like Lisp, follows what I'd call "Eval" semantics:  Under certain
conditions (such as message send) when a value is accessed, it is
"evaluated".  Most objects "evaluate" to themselves but methods "execute".
This has odd-ness associated with it (Ex.: store a method into an instance
variable, and into a local variable: this is non-symetric: accessing one
executes, accessing the other doesn't) and makes handling certain kinds of
values difficult (you must use "tongs", such as Self's mirrors).

Glyphic Script uses another slot type, orthagonal to the above type.  Slots
can be either "value" slots or "script" slots.  When accessing "value"
slots, the contents are always returned.  When accessing "script" slots,
the value is always "executed".  (It makes no sense for many values, such
as numbers, to sit in "script" slots - but it DOES make sense to have other
kinds of executable objects besides methods, one might have SQL queries...)
This scheme allows for one to handle script objects without tongs - except
when inserting them or extracting them from "script" slots (can't get away
from tongs completely!)

In the end, for most programmers, this distinction is minimal.  However, we
felt that the added slot "type" was easier to learn and work with then the
conceptual burdens of "Eval" semantics.  It also allowed us to write tons
of "instrospective" code (namely, the development environment itself) in
the system without the need for something like "mirrors".  Lastly, while
both systems could be extended to open the "evaluate"/"execute" property up
to user objects, it is very clear how you'd do this with slot type, but not
so with "Eval" semantics (Once you define the "evalutate" property for an
object, under "Eval" semantics you can no longer easily manipulate the
object!)

- Mark

--------------
*: For those of you that don't know: Glyphic Script is a language built
around a single-inheritance prototype object system.  It shares many
philosphical outlooks on life with Self, though the directions taken are
rather different.  It was represented at last year's OOPSLA panel on
Pototype langauges.  You can find out more (and get a demo copy for the
Mac) at:
        http://www.glyphic.com/glyphic/codeworks/intro.html

-------------------
Mark Lentczner
Glyphic Technology
1209 Villa Street
Mtn. View, CA 94041
415/964-5311
markl@glyphic.com
http://www.glyphic.com/