Re: categorizing traits objects

[John.Maloney@Eng.Sun.COM]

Greetings!

You asked several questions about the semantics of private category
slots in Self. I'll try to rephrase them and then answer them.

Q1: Why are category slots (sometimes) private?

I believe the idea was that the organization of an object's behavior
into categories should not be visible to its clients. However, I don't
believe we were consistent about this and I agree that it is a pain when
you are debugging. One way around this is to use the "enter" slot of the
shell object to make the prompt a child of the object you want to inspect.
Expressions evaluated at the prompt are then considered to come from "inside"
the object, so private messages can be sent without causes errors. For
example, you could say "enter: traits integer" and then "inspect: functions".

Q2: Why could you access the private slot "traits string printing"?

I don't know, since I don't have a copy of the released system handy.
But I believe that what you got was actually NOT the "traits string printing"
object (which was private) but some public "printing" object that was
visible from within "traits string", possible the one inherited from
"defaultBehavior".

We ourselves often got confused by the interaction of privacy,
mulitple inheritance, and the message lookup semantics. Thus, we
decided to simplify the language in several ways:

  1. Privacy is no longer supported by the VM. Thus, the slot found by
     a message lookup is not affected by the privacy declarations. The
     declarations are still used for documentation. At some point, we
     have plans to support privacy via slot renaming with support from
     the programming environment.

  2. All parents now have the same priority. This resulted in a vast
     simplification of the semantics of "resend".

We are close to releasing this new version of Self on our anonymous ftp
server. Keep watching this list for the release announcement.

	-- John