yms@beach.cis.ufl.edu (Yuh-Ming Shyy) (01/19/91)
Hi, I just came across an interesting scenario about an infinite loop of message passing. Any opinion will be highly appreciated. The problem happens when we model each method as an individual object, say, as an instance of a class called "METHOD". We can then define some methods for METHOD such as "eval", "compile", etc. Now, suppose class "STUDENT" defines a method called "eval_GPA", and we send a message "eval_GPA()" to a student "s1". What happens now is interesting: object "s1" checkes that "eval_GPA" is a method defined by "STUDENT", and so it sends a message "eval()" to the object "eval_GPA". Object "eval_GPA" will then checks and finds that "eval" is a method defined by class "METHOD", so it sends a message "eval()" to the object "eval". Object "eval" will then checks and finds that "eval" is a method defined by class "METHOD", so it sends a message "eval()" to itself recursively. The message "eval()" will then be sent back and forth between "eval" and "METHOD" and nothing can be actually evaluated. I am sure there must be something wrong with the above scenirio, but theoritically I cannot find any error (if we model everything as object as many people claimed). Thanks. Yuh-Ming
tma@osc.COM (Tim Atkins) (01/25/91)
Your error was that you had the Evaluator class confused with the Method class. They are simply not the same thing and therefore the cycle of eval messages would be broken. The buck has to stop somewhere. It is the very function of the Evaluator to take a method as argument to its eval function and actually execute it. - Tim
web@edsdrd.eds.com (William E. Bejcek) (01/28/91)
In article <4172@osc.COM> tma@osc.UUCP (Tim Atkins) writes: >The buck has to stop somewhere. It is the very function of the >Evaluator to take a method as argument to its eval function and >actually execute it. Exactly. We did an environment here, internally named OWL (not to be confused with Trellis/Owl from DEC), where "everything" is an object" including the "evaluator". We incorporated the concept of an external method (one coded in the native language) but having an object in the environment that represents it. Encapsulating the native code with a consistent protocol can introduce some really nice features. For example, in OWL, you can trap any object with additional instance level behavior. There are traps for tracing, breaking, & debugging that can be put on other behavior to aid with debugging. These work equally well on external methods as they do with standard intrepreted methods. The diffence is that you can trap the individual "statements" of a standard method (they are just objects that get eval'ed) giving finer granularity. Using the "all object" approach for behavior (a term that we use as a generalization of the standard method term) along with a consistent protocol provides a very powerful extensible environment. We've used this for defining inferencing behavior (logic, forward & backward chaining), properties, slot (instance variable) accesses, programable slots (i.v. x method), expainable slots (how did the value get there), etc. -- / William E. Bejcek / They choose the path where no one goes / / Electronic Data Systems / They hold no quarter, they ask no quarter - LZ / \ web@edsdrd.eds.com \ UUCP ... {rutgers!rel,uunet}!edsews!edsdrd!web \