> I'm in the SELF group here at SUN.
> What you seem to be asking for is sometimes called "behavioral reflection:"
> the ability of an object to define for itself how messages are looked up.
> It isn't clear from your message what you want to express that seems to
> require behavioral reflection. I think there may be ways to use dynamic
> inheritence to achieve the result you have in mind, by dynamically re-ordering
> chains of parents. Is the problem that you *cannot* order the parents
> uniquely? For example, if two parents p1 and p2 both have slots with
> names m1 and m2 AND you want p1's m1 behavior but p2's m2 behavior, then
> the parents would have to be re-ordered for each message. If that is
> your problem, you have several alternatives:
> a. re-factor your behavior into smaller chunks
> b. use a "transparent forwarder" object (an object that
> catches "undefinedSelector" and re-sends the message
> to the appropriate object). this is pretty close to
> what you seem to want
> c. use the reflective facilities to build an object with
> the right set of slots (Borning used this technique to
> implement multiple inheritance in Smalltalk)
> I believe that, however it is implemented, the ability to change an
> object's behavior dynamically should be used only sparingly, and in
> highly stylized ways. Otherwise, one can too easily create objects
> whose behavior is difficult or impossible to predict.
> -- John
I do seek a reflective capability. However, in a language with a
uniform presentation of behavior and state, I wonder if 'behavioral
reflection' is still the appropriate term.
I don't have any particular application in mind. I merely speculate
that dynamic inheritance, together with a reflective capability,
obviates the need for multiple inheritance support on the part of the
language. Perhaps simple inheritance is actually more general.
You correctly observe that there are cases in which *no* parent
ordering will have the desired inheritance. Moreover, by dynamically
reordering the parents, we defeat our purpose in having ordered them
in the first place. SELF will search the inheritance chain before our
object has the opportunity to specify its desired inheritance, so we
lose our opportunity for reordering anyway.
The 'undefinedSelector:' message cannot help our object since it is
delivered only after the inheritance chain has been searched. The
'transparent forwarder' (sometimes termed a 'proxy') is a special case
object that has no (or very little) behavior or state of its own. I
would hope that a reflective capability could apply more generally.
Besides, wouldn't this be a good way to implement proxies?
I may not understand what you mean by the 'right set of slots'. I
don't think that *any* set of slots is guaranteed to match the messages
that might be sent to an object. I can send an arbitrary set by typing
them in at the keyboard.
I completely agree with your last point. David Ungar expressed a similar
concern in his first paper on SELF (how is one *supposed* to program in
SELF, anyway?). But since no language is sufficient to make a good
programmer of a bad one (axiom here), I believe that any attempt by
language developers to constrain or enforce 'correct' programming is
Lee Murach Tel: (805) 485-2700
Network Research Corp. FAX: (805) 485-8204
2380 North Rose Avenue Internet: lee(a)nrc.com
Oxnard, CA 93030 CompuServe: 71161,651