changed: #virtualMachineRelationship
authorClaus Gittinger <cg@exept.de>
Wed, 07 Apr 2010 20:08:01 +0200
changeset 12858 695cbd35ce8a
parent 12857 2a99557cf850
child 12859 f973aadfb3d2
changed: #virtualMachineRelationship documentation
Behavior.st
--- a/Behavior.st	Wed Apr 07 19:51:57 2010 +0200
+++ b/Behavior.st	Wed Apr 07 20:08:01 2010 +0200
@@ -93,16 +93,16 @@
 virtualMachineRelationship
 "
     Expert info follows:
-
+    --------------------
     NOTICE:
-	the stuff described below may not be available on other
-	Smalltalk implementations; be aware that these error mechanisms
-	are ST/X specials and applications using these (tricks) may
-	not be portable to other systems.
+        the stuff described below may not be available on other
+        Smalltalk implementations; be aware that these error mechanisms
+        are ST/X specials and applications using these (tricks) may
+        not be portable to other systems.
 
     WARNING:
-	do not try the examples below on (some) other smalltalk systems;
-	it has been reported, that some crash badly when doing this .... ;-)
+        do not try the examples below on (some) other smalltalk systems;
+        it has been reported, that some crash badly when doing this .... ;-)
 
     Instances of Behavior and subclasses (i.e. in sloppy words: classes)
     play a special role w.r.t. the VM. Only objects whose class-slot is marked
@@ -113,14 +113,14 @@
 
 
     Why is this so:
-
+    ---------------
     the above lets every object play the role of a class,
     which has been flagged as behaviorLike in its class's flag.
     Thus, you can create arbitrary new classLike objects and have the VM
     play with them.
     This may offer the flexibility to create a totally different object scheme
     on top of ST/X (for example: Self like objects) where any object can play
-    a classRole for another object.
+    a classRole for another object or even for itself.
 
     [A concrete application of this is found in the Structure class,
      which creates objects which are their own class !!
@@ -132,9 +132,9 @@
     object, the VM EXPECTS the object selector and methodDictionaries to be found
     at the instance positions as defined here.
     (i.e. instanceVariables with contents and semantic corresponding to
-	superclass
-	flags
-	methodDictionary
+        superclass
+        flags
+        methodDictionary
      must be present and have the same instVar-index as here).
 
     The VM (and the system) may crash badly, if this is not the case.
@@ -149,7 +149,7 @@
 
 
     Vice versa, defining 'dumb classes', which have the behaviorLike bit turned
-    of may be useful as well; if a message is sent to an instance of such
+    off may be useful as well; if a message is sent to an instance of such
     a thingy, the VM performs a recovery sequence, which is much like the
     #doesNotUnderstand: mechanism - however, since the instance is no good
     receiver of such a message, a #cannotSendMessage:to: is now sent to the
@@ -167,111 +167,132 @@
 
 
     Examples (only of theoretical interest):
-	take away the behaviorLike-flag from a class.
-	-> The instances will not understand any messages, since the VM will
-	   not recognize its class as being a class ...
-
-	|newMeta notRecognizedAsClass someInstance|
-
-	newMeta := Metaclass new.
-	newMeta flags:0.
-
-	notRecognizedAsClass := newMeta new.
-
-	someInstance := notRecognizedAsClass new.
-	someInstance perform:#isNil
+    ----------------------------------------
+        take away the behaviorLike-flag from a class.
+        -> The instances will not understand any messages, since the VM will
+           not recognize its class as being a class ...
+
+        |newMeta notRecognizedAsClass someInstance|
+
+        newMeta := Metaclass new.
+        newMeta flags:0.
+
+        notRecognizedAsClass := newMeta new.
+
+        someInstance := notRecognizedAsClass new.
+        someInstance perform:#isNil
 
 
     Of course, this is an exception which can be handled ...:
     Example:
 
-	|newMeta notRecognizedAsClass someInstance|
-
-	newMeta := Metaclass new.
-	newMeta flags:0.
-
-	notRecognizedAsClass := newMeta new.
-
-	someInstance := notRecognizedAsClass new.
-	Object errorSignal handle:[:ex |
-	    ex return
-	] do:[
-	    someInstance perform:#isNil
-	]
+        |newMeta notRecognizedAsClass someInstance|
+
+        newMeta := Metaclass new.
+        newMeta flags:0.
+
+        notRecognizedAsClass := newMeta new.
+
+        someInstance := notRecognizedAsClass new.
+        Object errorSignal handle:[:ex |
+            ex return
+        ] do:[
+            someInstance perform:#isNil
+        ]
 
 
     likewise, a doesNotUnderstand-notUnderstood can be handled:
     Example:
 
-	|newMeta funnyClass someInstance|
-
-	newMeta := Metaclass new.
-
-	funnyClass := newMeta new.
-	funnyClass setSuperclass:nil.
-
-	someInstance := funnyClass new.
-	Object errorSignal handle:[:ex |
-	     ex return
-	] do:[
-	    someInstance perform:#isNil
-	]
+        |newMeta funnyClass someInstance|
+
+        newMeta := Metaclass new.
+
+        funnyClass := newMeta new.
+        funnyClass setSuperclass:nil.
+
+        someInstance := funnyClass new.
+        Object errorSignal handle:[:ex |
+             ex return
+        ] do:[
+            someInstance perform:#isNil
+        ]
 
 
     more examples, which try to trick the VM ;-):
-	badly playing around with a classes internals ...
-
-	|newClass someInstance|
-
-	newClass := Class new.
-	newClass setSuperclass:nil.
-	someInstance := newClass new.
-	someInstance inspect
-
-
-	|newClass someInstance|
-
-	newClass := Class new.
-	newClass setSuperclass:newClass.
-	someInstance := newClass new.
-	someInstance inspect
-
-
-	|newClass someInstance|
-
-	newClass := Class new.
-	newClass setSuperclass:1.
-	someInstance := newClass new.
-	someInstance inspect
+        badly playing around with a classes internals ...
+
+        |newClass someInstance|
+
+        newClass := Class new.
+        newClass setSuperclass:nil.
+        someInstance := newClass new.
+        someInstance inspect
+
+
+        |newClass someInstance|
+
+        newClass := Class new.
+        newClass setSuperclass:newClass.
+        someInstance := newClass new.
+        someInstance inspect
+
+
+        |newClass someInstance|
+
+        newClass := Class new.
+        newClass setSuperclass:1.
+        someInstance := newClass new.
+        someInstance inspect
+
+
+    Example:
+        creating totally anonymous classes:
+
+        |newClass someInstance|
+
+        newClass := Class new.
+        someInstance := newClass new.
+        someInstance inspect
 
 
     Example:
-	creating totally anonymous classes:
-
-	|newClass someInstance|
-
-	newClass := Class new.
-	someInstance := newClass new.
-	someInstance inspect
-
-
-    Example:
-	creating totally anonymous metaclasses:
-
-	|newMeta newClass someInstance|
-
-	newMeta := Metaclass new.
-	newClass := newMeta new.
-	someInstance := newClass new.
-	someInstance inspect
+        creating totally anonymous metaclasses:
+
+        |newMeta newClass someInstance|
+
+        newMeta := Metaclass new.
+        newClass := newMeta new.
+        someInstance := newClass new.
+        someInstance inspect
 
 
     PS: if you experiment with new behaviorLike objects, you may want
-	to turn off the VM's debugPrintouts
-	with:
-		'Smalltalk debugPrinting:false'
-	and:
-		'Smalltalk infoPrinting:false'
+        to turn off the VM's debugPrintouts
+        with:
+                'Smalltalk debugPrinting:false'
+        and:
+                'Smalltalk infoPrinting:false'
+
+    Meta-Object-Protocol support:
+    -----------------------------
+    the above tricks do not affect the inline caches, and are therefore somewhat slow.
+    Another hook is the lookupObject which, if non-nil, is consulted to do the lookup
+    instead of the hardwired VM lookup algorithm, and provide a method as return value.
+    This method (if non-nil) will be put into the inline-and polymorph caches for speedy
+    call the next time. If non-nil, the lookup object is sent the:
+            lookupMethodForSelector:aSelector 
+            directedTo:searchClass 
+            for:aReceiver 
+            withArguments:argArrayOrNil 
+            from:sendingContext
+    message.
+    'searchClass' is the object class or any of its superclasses (for directed/super sends).
+    You can return any arbitrary method there - for example to implement multiple inheritance,
+    selector namespace tricks or multi-dispatch on argument types (double dispatch for a method).
+    Be aware, that the returned method is cached, and the lookup is not consulted again for the
+    same receiver/callsite combination. So the returned method should check if it's ok to be called
+    again (maybe, a synthetic method is generated and returned).
 "
 ! !
 
@@ -4546,9 +4567,9 @@
 !Behavior class methodsFor:'documentation'!
 
 version
-    ^ '$Header: /cvs/stx/stx/libbasic/Behavior.st,v 1.301 2010-04-07 17:50:20 cg Exp $'
+    ^ '$Header: /cvs/stx/stx/libbasic/Behavior.st,v 1.302 2010-04-07 18:08:01 cg Exp $'
 !
 
 version_CVS
-    ^ '$Header: /cvs/stx/stx/libbasic/Behavior.st,v 1.301 2010-04-07 17:50:20 cg Exp $'
+    ^ '$Header: /cvs/stx/stx/libbasic/Behavior.st,v 1.302 2010-04-07 18:08:01 cg Exp $'
 ! !