Re: MI in SELF

[Charles (Froggy) Fiterman <cef@blistr.mwc.com>]

>
>Lee,
>
>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

There is another behavior that might be appropriate. The compiler could
inform me of the ambiguity of p1.m1 and p2.m1 etc and suggest I resolve it.
This is close to the behavior of Eiffel which treats all parents as equal
and all ambiguity as mortal error.

There can be a continum between prototyping languages and systems engineering
languages. A programmer could begin by writing a prototype in Self. If the
user liked it but needed something more solid the programmer could start 
turning on the checks, eventually producing a fully type checked program
where all messages were guaranteed a good destination. I find type checking a
good debugging tool.

As applications evolve I often wish for an easy way to change the inheritance
tree. I see no use for a dynamically changing tree but so much of programming
has come from making things first class objects, why not the inheritance
tree. I say this not with some application in mind but in spirit of
exploration.

Further I often wish to say x is a child of y where x has no internal
relation to y but follows the same behavior. In c++ and Eiffel this is
impossable, there is nothing the compiler could generate. In Self it is
unnessisary because there is no type checking. But if Self had lint tools to
become a systems engineering language. It could be the best systems
engineering language in the world.

Again I propose completely dividing inheritance into two notions. Genetic
inheritance which has to do with construction and message passing. And
logical inheritance which has to do with type checking and has no relation to
internal structure or message passing.

-- 
cef@mwc.com		 Spelling errors in this document are
708-291-6700 x119	caused by uucp compression algorithims