jcg@iris.brown.edu (James Grandy) (04/06/90)
In article <8756@imag.imag.fr> frechen@imag.imag.fr (Francois RECHENMANN) writes: > IUm trying to see the interest of separating object hierarchies from >method hierarchies in Object-Oriented Programming Languages and Knowledge >Bases. I think there are some cases where methods imply an object hierarchy >which conflicts with the notion of specialization the implementor has in >mind. That is, thereUs a conflict between reuse of code and specialization. > > What IUm looking for are examples of such situations. People using >Smalltalk may think to cases where the send-super mechanism must jump over >a superclasse, but there must be other situations. > Could people having encountered that mail me or publish here their >examples ? I think this can be the beginning of an interesting talk. One need for a method hierarchy has to do with the sequencing of methods to respond to a message. To be more specific: certain messages will require that methods be activated in a certain sequence. For instance, in MacApp there is the notion of an event handler chain, which is a linked list of objects representing user interface entities (selections, views, windows, documents, etc.) to be followed when responding to a message. Typically, in responding to a message, the list is traversed from tightest scope (e.g. selection) to broadest (e.g. application). In addition, each event handler responds to the message by invoking every method in the subclass to superclass chain. Thus, if the handler chain contains a selection, a view and a window (for instance), the sequence of methods invoked might look like this: selection: Selection|handle, EventHandler|handle view: View|handle, Pane|handle, EventHandler|handle window: Window|handle, View|handle, Pane|handle, EventHandler|handle In other words, there is a very distinct sequence of methods to be invoked to respond to the handle message. This sequence is usually encoded in the text of each method, in the form of super sends and "nextHandler handle" messages. There are several reasons why this is not a good way of doing things: * it's hard to maintain, because every method has to implement the sequencing redundently * it's hard to teach, because every implementor of an event handler must understand this mechanism I've been working on various ways of extracting the sequencing information from the methods, and have come up with what I call "method sequencers". These are methods which do the method lookup in response to a message, except they can invoke multiple methods. The methods themselves have no knowledge of the larger sequence in which they exist. This is not really a "method hierarchy" in the sense I think you mean, because there is not necessarily any relationship between the methods which participate in a sequence. However, if you define a single method sequencer over all methods defined for a particular method (i.e. whenever you send the message "handle", the same sequencer is invoked), then you are in effect defining a "family" of methods, similar in that each partially implements the "semantics" of the message. James Grandy (401) 862-1610 jcg@iris.brown.edu IRIS Brown University Box 1946, Providence, RI 02912