Re: slot types

[David.Ungar@Eng.Sun.COM (David Ungar)]

Hi all,

Here is a long-delayed response to Mark's message about slot types.
Let me say first that there although is a lot I admire in Glyphic,
but this slot type stuff worries me a bit.
Let me see if I can say why.

First, there seem to be a lot of possibilities:
3 types: Copied, Global, or Private
multiplied by
2 types: script or value

= 6 total combinations

I have a feeling that not all of these combinations are sensible:
for instance do I need a copied script slot?
6 possibilities seems like a lot.


The Private type seems like a big hammer for a small nail--
if you could talk about "thisMethodHolder" would you still need it?
You could replace a private slot by a method that tested if
something were == to thisMethodHolder.

Copied & Global may well be unavoidable; we have something similar
in the Self environment (though not the language).

Finally Script & Eval:

I would not say that Self, like Lisp has Eval semantics exactly
the way Mark does: Lisp only evaluates the first argument, but Self
evaluates everything.
Also, Mark talks about the odd-ness that results from storing a method
into an instance var vs. a local var, but there is none.
You cannot store a method into a variable, only a constant.
(That may be odd, but I belive that Glyphic has a similar problem:
if you have a script slot called "x", and you send "x:" I think
it tries to run the script with an extra argument rather than send "x:"
to the container.)

The Glyphic approach of having two slot types gets into trouble,
(as Mark points out) because again, not every combination makes sense.
As far as writing "introspective" code, I'm not sure which approach
is better; it seems the same to me.
In Self, introspective code works with mirrors, and the difficulty
is knowing when you get a mirror vs. a plain object.
In Glyphic, introspective code works with objects, but still needs magic
to extract a method out of a script slot, just as Self needs magic
to create that mirror for the method.
Also in Glyphic, introspective code has to deal with an extra type of slot,
(in addition to understanding script objects)
whereas in Self, introspective code has only to deal with one slot type,
(in addition to understanding script objects).
So the introspective code angle seems a wash to me.

So, except for the Global/Copied distinction, the slot types
seem to create a lot of combinations to deal with,
that don't always seem very useful.
I'm not sure their benefits sufficiently compensate for their drawbacks.


At 1:09 PM 9/13/95, Mark Lentczner wrote:
>(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/

-- Dave