Definition of privacy in Self

[dje@scs.carleton.ca (Danny Jared Epstein)]

I agree!  The current definition of privacy in Self is hard to
understand.

> "A private slot is accessible if both the sending method holder
> and the private slot holder are ancestors of the receiver."

The two parts of this definition correspond to being able to see the
slot and being able to see *into* the slot:

  Any slot is accessible if the slot holder is an ancestor of the
  receiver and the slot is visible.  A public slot is always visible.
  A private slot is visible if the sending method holder is an
  ancestor of the receiver.

If we assume that the receiver is the private slot holder (ie. the
private slot is not being inherited), then the visibility requirement
becomes:

  A non-inherited private slot is visible if the sending method
  holder is an ancestor of the private slot holder.

In other words, you can see private slots in your children rather than
in your parents.  This is the opposite condition as that used in
Trellis/Owl.  On the other hand, the definition makes sense in Self
since we want a traits object to be able to access the private slots
in its children.

When the private slot is inherited, the requirement becomes less
strict: the sending method holder only needs to be an ancestor of the
receiver (rather than the private slot holder).  This means than you
can see a private slot in your parents but only if you send the
message to yourself.  You can't see private slots in your parents if
you send the message directly to them.  For example, a list could send
collectionName to itself but not to its parent (traits list), even
though the slot is defined in the parent.

I've been trying to make sense out of Self's privacy rules for some
time.  They seem to work as you would expect most of the time.  There
are times when the rules seem too strict, making it necessary to
comment out the privacy constraint on a slot.  This is done several
places in the built-in Self code.  Also, I often find it necessary to
add a slot to an object directly rather than putting it in the
appropriate parent "protocol" object because the parent is private.
There should be some way to circumvent the privacy in this case.

It is worth pointing out that if "protocol" objects (parents
containing a group of related methods) inherited from the lobby, the
above problem would disappear.  Other problems also occur because of
this: protocol objects don't understand error handling messages, for
example.  I would suggest adding a piece of syntactic sugar (syntactic
short-hand) to let you define a protocol which would have 'traits
protocol' as a parent.  All protocols would then inherit from the
lobby, making them visible from the lobby and making them understand
error messages.

I hope this helps some of you understand how Self's visibility rules
work and why.


- Danny Epstein
  dje@scs.carleton.ca