Re: categorizing traits objects

[R James Noble <kjx@comp.vuw.ac.nz>]

I've recently caught up with current batch of messages on the list
(insert generic wry graduate-student-writing-thesis comment :-) so
here are some belated comments about multiple inheritance and privacy.

In general, I like the move towards a smaller language, and certainly
the current inheritance and privacy facilities of Self are not
particularly simple. But I think the information hiding and
encapsulation of objects is an important part of the OO approach, and
hope that Self's facilities in these areas will continue to evolve.

Urs> Privacy ... a kind of stylized comment indicating your intention,

So the syntax of privacy declarations are unchanged, privacy
information is still available via mirrors, but slot privacy is
ignored in program execution? 


Urs> In particular, privacy had no notion of "friend" - collaborating
Urs> objects that have more access than the rest of the world but aren't
Urs> related via inheritance.

Yes. One idea I had was to extend the old scheme with "zero-priority
parent" slots. They would act as other parent slots for the purposes
of privacy checking (and directed resends) but would not be searched
by the default lookup algorithm. This would provide the hole in the
privacy algorithm, but without the problems of normal inheritance
(even at low priority, unwanted messages can be inherited).  I have
used a programming device I've called "enemies" to much the same
effect.  For example, I say that

    example = (|
	^ enemy = (|
	    p* <- target.
	    foo = (resend.foo).
	    bar = (resend.bar).
	|).
	

	doFooToTarget = (enemy foo).
    |)

makes object example an "enemy" of object target as far as messages
foo and bar are concerned. This is much the same as target's members
foo and bar being friends of example, but the link is the wrong way
round.

Therefore, where C++ has friends, Self has enemies. :-)


John> Priorities... It is easy to write forwarding methods of the
John> form: "foo = (parent1.foo)" to accomplish this

I guess these methods could also be "handled automatically in the
programming environment".

Urs> Well, without parent priorities resend becomes very simple since
Urs> it always searches upwards starting from the resending method
Urs> holder.

With the revision of inheritance and privacy, has the "delegated
perform" been changed? The new privacy scheme should remove some
problems --- currently, the lookup for the receiver's private
methods starts in the delegatee,  but the delegatee cannot necessarily
access those slots. However, a "method holder" parameter is probably
needed here, as mentioned in the code.

This would be useful for my "encapsulators" for monitoring objects,
but should be powerful enough to implement general per-object message
dispatching, but without the necessity for a full meta-level.  It
should be quite possible to use this to simulate prioritised multiple
inheritance at runtime, or even dynamically construct the above
forwarding methods.

James Noble
kjx