Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!swiss.ans.net!gatech!swrinde!elroy.jpl.nasa.gov!ames!cnn.nas.nasa.gov!hultquis
From: hultquis@nas.nasa.gov (Jeff P. M. Hultquist)
Subject: SUMMARY -- delegation after doesNotUnderstand: 
Message-ID: <HULTQUIS.94Sep23102329@wk206.nas.nasa.gov>
Sender: news@cnn.nas.nasa.gov (News Administrator)
Nntp-Posting-Host: wk206.nas.nasa.gov
Reply-To: hultquis@nas.nasa.gov
Organization: NASA/Ames Research Center
Date: Fri, 23 Sep 1994 17:23:29 GMT
Lines: 409

 

A while back, I posted a message about using
delegation of messages for recovery in the 
doesNotUnderstand method.  Here is the original
posting, followed by a set of responses. 

 
:--------------------------------------------------
:   Newsgroups: comp.lang.smalltalk
:   Path: cnn.nas.nasa.gov!hultquis
:   From: hultquis@nas.nasa.gov (Jeff P. M. Hultquist)
:   Subject: a cute hack -- delegation after doesNotUnderstand 
:   Sender: news@cnn.nas.nasa.gov (News Administrator)
:   Nntp-Posting-Host: wk206.nas.nasa.gov
:   Reply-To: hultquis@nas.nasa.gov
:   Organization: NASA/Ames Research Center
:   Date: Thu, 15 Sep 1994 21:09:33 GMT
:   
:   
:   A friend (Eric Raible, raible@nas.nasa.gov) and I have
:   written a Smalltalk-like object system under Scheme -- it
:   has single-inheritance, and lookup of methods using the
:   message and the class of the receiver.  And if the
:   recipient has no acceptable method, then the receiver is
:   then sent the message doesNotUnderstand.  The method for
:   doesNotUnderstand (defined in the class Object) simply
:   calls the debugger.  So far, so good, and Just Like
:   Smalltalk.
:   
:   We recently changed the method for doesNotUnderstand so
:   that, before calling the debugger, it first checks if the
:   receiving instance can provide us with one or more
:   "delegate instances" which should receive the original
:   method in its place.  If a delegate *is* provided, the
:   system sends the original message to that object and the
:   execution continues unimpeded.
:   
:   This has proven to be extremely helpful, and has
:   eliminated many of the occasions in which we would
:   otherwise have wanted multiple-inheritance.  For example,
:   if we have a SET instance, we might choose to forward any
:   unsupported messages to all of the elements within that
:   set.  Thus, a set of WINDOW instances can be redrawn by
:   sending the "redraw" message to the set itself.  The
:   message-lookup fails and triggers the sending of the
:   "doesNotUnderstand" message to the set.  That method now
:   sends the message "delegate" to the same set, receives the
:   list of delegate instances, and then sends the original
:   message "redraw" to all of these instances.
:   
:   Anyway, I think that this is a very cute and useful (and
:   original?) hack, and that why I am posting it.  -- So that
:   others might benefit from this idea, and perhaps so that
:   someone might inform *me* of prior use of this technique
:   or related uses of the doesNotUnderstand method.
:   
:   --
:   Jeff Hultquist                         hultquis@nas.nasa.gov
:   NASA - Ames Research Center                   (415) 604-4970
:   
:--------------------------------------------------
:   From: Richard L. Peskin <peskin@caip.rutgers.edu>
:   Newsgroups: comp.lang.smalltalk
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand
:   Date: 15 Sep 1994 17:30:46 -0400
:   Organization: Rutgers Univ.
:   
:   >...
:   
:   A similar technique was used to implement something called "Futures",
:   which was a sort of "parallel" computing technique for Smalltalk. At one
:   time, this was on the Manchester Goodies site. Futures was a paradigm
:   similar to that used in "multi-Lisp".
:   --dick peskin
:   =================================
:   R. L. Peskin,  Rutgers Univ. ; <peskin@caip.rutgers.edu>;  908/932-3685
:   "Good work is always done in defiance of management."  R. Woodward
:   
:   
:--------------------------------------------------
:   From: jwarmer@ckt.hut.nl (Jos Warmer)
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand 
:   content-length: 1070
:   
:   In article <HULTQUIS.94Sep15140936@wk206.nas.nasa.gov> Jeff P. M.
:   Hultquist, hultquis@nas.nasa.gov writes:
:   > We recently changed the method for doesNotUnderstand so
:   > that, before calling the debugger, it first checks if the
:   
:   I don't have acces to post news, therefore I answer by email.
:   You may post this if it seems useful.
:   
:   This type of use for the doesNotUnderstand method is being used by
:   advanced Smalltalkers. I recall that Wilf LaLonde and John Pugh wrote
:   about its use in the Journal of Object Orienetd Programming (JOOP).
:   The issue of JOOP, october 1993 has an article called "idle time
:   computing with futures", which makes use of the same feature.
:   
:   In their book "Smalltalk/V : Practice & Experience" their are also chapters
:   in which the same 'trick' is used.
:   
:   Both of these references are very good.
:   
:   Greetings, Jos Warmer
:   
:         Jos Warmer
:   
:         Centrum voor Kennistechnologie         tel  : 030 308100
:         Kaatstraat 41                          fax  : 030 328195
:         Postbus 573
:         3500 AN Utrecht                        email: jwarmer@ckt.hut.nl
:   
:--------------------------------------------------
:   From: kentq@world.std.com (Kent J Quirk)
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand
:   Organization: The World Public Access UNIX, Brookline, MA
:   Date: Fri, 16 Sep 1994 01:42:58 GMT
:   
:   I have heard of the same technique being used to implement distributed 
:   computing.  Objects residing on other machines across the net have a 
:   "dumb" object locally whose only method is doesNotUnderstand.  This local 
:   object packages up the original message, sends it to the "real" object, 
:   collects the result, and then answers the result.
:   
:   *Poof*.  Redirection across the net with no changes to the parent source 
:   code.
:   
:--------------------------------------------------
:   From: bgowing@cs.tcd.ie (Brendan Gowing)
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand 
:   Organization: Computer Science, Trinity College Dublin
:   
:   >...
:   
:   This was also how the Actalk system was implemented in Smalltalk.
:   See: J.P. Briot, `Actalk: a Testbed for Classifying and Designing
:   Actor Languages in the Smalltalk-80 Environment', ECOOP '89.
:   
:   -BG
:   
:   -- 
:   Brendan Gowing      Distributed Systems Group, Dept.of Computer Science, 
:   ----///--------  ---------- Trinity College, Dublin 2, Ireland. ----------
:   \\\///    EMail: bgowing@dsg.cs.tcd.ie               Phone: +353-1-7021782
:    \XX/     WWW:   http://www.dsg.cs.tcd.ie:/dsg_people/bgowing/bgowing.html
:   
:--------------------------------------------------
:   From: cbrown@fx.net (Chris Brown)
:   Newsgroups: comp.lang.smalltalk
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand
:   Date: 16 Sep 1994 16:17:04 GMT
:   
:   
:   Similaryly, I recently reimplemented the doesNotUndertstand message in
:   VW 1.0 for delegation purposes. We designed the system around a
:   Entity-Role thought by which the Entity i.e a person coul play many
:   roles in the system. Each role would have the specific behavior of
:   that that role (role of a spouse) and be able to "inherit" the
:   behavior of the entity.  In actuality, we wanted the role to be able
:   to have all the behavior of the entity by delegating all messages to
:   the entity (i.e name).
:   
:         I reimplented the doesNotUnderstand message in the Role
:   class. When a role subclass received a message that it did not
:   comprehend, it would first ask the entity attached to it if it
:   understood the message. If the entity did understand the message, the
:   instance of the entity class would perform said message; else a super
:   doesNotUnderstand would be performed with a debug window.
:   
:        This implementation gave us all the behavior through delegation
:   from the entiity classes to the role classes that you needed and
:   prevented us from having to re-implemented all the messages at the
:   Role class level from the Entity class( delegation by passing
:   through).
:   
:   [...]
:   
:--------------------------------------------------
:   From: shulok@progress.com (Thom A. Shulok)
:   Newsgroups: comp.lang.smalltalk
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand
:   Organization: Progress Software
:   
:   >>...
:   
:   Cute, perhaps, but be aware that hooking doesNotUnderstand is
:   extremely inefficient.  I wouldn't recommend building a system that
:   relied too heavily on this.
:   
:   Thom
:   
:--------------------------------------------------
:   From: Vadim Sokolovsky <vadim@panix.com>
:   Subject: Re: a cute hack -- delegation after doesNotUnderstand 
:   Newsgroups: comp.lang.smalltalk
:   
:   Jeff,
:   
:   	The idea of reimplementing doesNotUnderstand is really very
:   cute (and dangerous). The fact that you came up with it on your own
:   makes you a compliment. This approach is used in some commercial
:   systems. (At least GemStone ODBMS uses it to implement forwarders and
:   stubs). However it is just a work around, not a true MI. (I admit -
:   never saw a real MI in Smalltalk though I know that it is possible to
:   implement it)
:   
:   Regards,
:   Vadim
:   GreenPoint, Inc
:   
:--------------------------------------------------
:   From: quasar@qks.com (David Simmons)
:   Subject: [SmalltalkAgents] Re: a cute hack -- delegation after doesNotUnderstand
:   
:   >...
:   
:   Hi Jeff,
:   
:   QKS'es SmalltalkAgents provides four mechanisms for accomplishing this kind
:   of activity.  You may want to look into adding similar techniques to your
:   Scheme code-base.
:   ____
:   Technique #1: Use bind-failure delegation as you have now. This technique
:   has been used in Smalltalk for quite a long time now.
:   ____
:   Technique #2: Add object specific methods (SmalltalkAgents allows objects
:   to have their own methods like SELF does).
:   ____
:   Technique #3: SmalltalkAgents virtual machine (VM) supports a number of
:   object properties. The following are two that are relevant to distributed
:   objects and databases.
:   
:   Set the object property for "bind notification".  This allows all messages
:   which are sent to an object to be intercepted prior to the bind-dispatch in
:   the VM.  A handler can then choose to route the message in whatever fashion
:   is required.  This has the advantage that since it comes before the bind it
:   can be used to shadow/override an objects inherited methods.
:   
:   A related object property is the "access notification" property that
:   enables an object to intercept all slot getter and setter operations.  This
:   is used for database and distributed object operations.
:   
:   Both of these properties are supported at the VM level for all objects and
:   thus they can be used in any situation without needing to redesign the
:   affected classes or objects.  The notification/interception mechanisms are
:   transparent to the affected objects.
:   
:   When combined with the SmalltalkAgents real-time object linking mechanism
:   (PIPO - platform independent portable object packages) this becomes an
:   extremely powerful way to support distributed objects.  It is far more
:   powerful than the HP-Distributed Smalltalk mechanisms.  Primarily because
:   you can import or export some 1200 objects/second where the objects can be
:   anything include block-closures, threads, buttons, windows, classes,
:   compiled-methods, collections...  Them mechanism is a linker as well so it
:   enables references to entities in the SmalltalkAgents multiple-namespace
:   system to be carried with the objects.
:   
:   e.g., you might write code to do the following:
:   
:       objectPackage :=
:       {object. more objects...} archiveWithInitializer:
:       [:package |
:           ... unarchive action block ...
:       ].
:   
:       databaseTable addRecord: objectPackage withKeys: {keys...}.
:   
:       tcpSocket sendObjectPackage: objectPackage.
:   
:       aFileStream nextPutAll: objectPackage.
:   
:       ----
:       IN THE FOREIGN ENVIRONMENT YOU MIGHT DO:
:   
:       unarchivedPackage := tcpSocket readObjectPackage unarchive.
:   
:       unarchivedPackage := ((ArchivedObject new) replaceStorageWith:
:           (databaseTable retrieveRecordWithKeys: {keys...})) unarchive.
:   
:       unarchivedPackage := (ArchivedObject importFromFile: fileSpecifier)
:           unarchive.
:   ____
:   Technique #4: Use the SmalltalkAgents "Semantic Message" system that
:   supports multi-casting of messages, service registration, and service
:   subscription.  It also provides dynamic inheritance through a "inheritance
:   layer" system.
:   
:   A typical usage is to have a "module" that provides a module-layer. A
:   window then dynamically attaches itself to the module-layer.  The window
:   also provides its own window-layer.
:   
:   By the way, a module in SmalltalkAgents is an "application".  The
:   SmalltalkAgents architecture allows multiple modules to share the Smalltalk
:   environment thus reducing the memory constraints and providing a very
:   efficient means for inter-application coupling.
:   
:   Any components in the window attach themselves to the window's layer.
:   Whenever a message is "smPerformed..." it will be routed through the
:   semantic message architecture.  Un-handled messages to a component are
:   automatically routed throught its containing layer to its window, and if
:   still not handled then they go to the module.
:   
:   Note that every object can provide its own layer and any object can
:   dynamically attach or remove itself from a layer.
:   
:   The service registry, subscription, and multicasting are a client/server
:   messaging and dependency system.  An object like a button might provide the
:   "service" of #buttonRelease.  A window containing that component might
:   subscribe to the #buttonRelease and re-route the behavior.
:   
:      myWindow addComponent:
:      ((Button new)
:           ...button characteristics...
:           on: #buttonRelease send: #doMyAction to: myWindow
:      ).
:   
:   Similarly there may be child windows that all want to be notified
:   (multi-cast) when a given parent window becomes active or inactive
:   (focusing).
:   
:      parentWindow
:           on: #activating: send: #parentActivating: to: child1.
:      parentWindow
:           on: #activating: send: #parentActivating: to: child2.
:      parentWindow
:           on: #activating: send: #parentActivating: to: child3.
:   
:   Note that you can also do:
:   
:      foo
:          on: #somethingChanged do: [...statements].
:   
:   Whenever the parent window smPerforms its <#activating:> behavior, each of
:   the subscribers (the child windows) will be sent their respective messages.
:   I have only provided a very basic overview of the SmalltalkAgents
:   semantic-message system.
:   
:   It actually provides mechanisms for retaining the message bindings so that
:   "design" can be captured and stored to enable the creation of "plug & play"
:   components.  In addition to the Agents Presentation Manager framework, it
:   also is used in a variety of other frameworks.
:   
:   A typical design example would be to build a "view" (or pane) that
:   contained all the "semantic bindings" that it would need when it was
:   installed into a component container.  Upon being installed it
:   automatically registers its bindings and becomes an integrated member of
:   the container.  More importantly when it is dynamically removed from the
:   container it would automatically unregister its bindings.
:   
:   A trivial example might be a text field that wanted to intercept all
:   keystrokes and wanted to catch window deactivation/activation.  The
:   text-field would own all the necessary semantic-messages for supporting
:   these operational/design requirements. When it was added to a window it
:   would install its bindings (transparent to the window or its design) and
:   subsequently when the button was removed its would uninstall its bindings.
:   The architecture provided removes the burden of dynamic bindings management
:   from the designer of the window and from the designer of the button.
:   
:   The ability to install and uninstall components dynamically (in real-time)
:   is very important because it forms the basis for "morphing" user interfaces
:   for various look and feels.  It is also needed for dynamically composed
:   views like those that are used for forms based applications and for
:   managing structured SGML or HTML documents.
:   
:   ----------
:   I hope the forgoing ideas made some sense and prove useful for you.
:   
:   Best Regards,
:   
:   -- Dave S.
:   
:   ----------------------------------
:   SmalltalkAgents Architecture Group
:   ----------------------------------
:   Quasar Knowledge Systems, Inc. [QKS]
:   9818 Parkwood Drive, Bethesda, MD 20814 USA
:
:   PHONE           : (301) 530-4853
:   FAX             : (301) 530-5712
:   INTERNET        :  dsimmons@qks.com.
:   from AppleLink  : "DSIMMONS@QKS.COM@INTERNET#"
:   from CompuServe : "INTERNET:dsimmons@qks.com"
:   Product or
:   Technical Info  : (Please send all inquiries to info@qks.com)
:  
:--------------------------------------------------
:   From: dsiegel@panix.com (David Siegel)
:   Newsgroups: comp.lang.smalltalk
:   NNTP-Posting-Host: panix.com
:  
:   In <Cw89v4.Mo9@txnews.amd.com> charles.herrick@amd.com writes:
:   >I believe Servio GemStone uses override of doesNotUnderstand: to get
:   >messages across the two-space...
:  
:   It uses doesNotUnderstand: to fault in proxied objects.
:  
:   >And (my memory fades here, take this with a grain of salt), 
:   >doesn't the Smalltalk I'face to ISIS (RDO: Reliable Distributed Objects)
:   >use override of doesNotUnderstand: to get messages across the wire?
:  
:   Yes, as does HP's DST, and as did the remote Smalltalk Xu Wang
:   implemented at Queens'.  It's traditional.
:   
:   -dms
:--------------------------------------------------
--
Jeff Hultquist                         hultquis@nas.nasa.gov
NASA - Ames Research Center                   (415) 604-4970
