I did not tried in Squeak but you can be interested by the following 
article
Evaluating Message Passing Control in Smalltalk 
http://www.iam.unibe.ch/~ducasse/WebPages/Publications.html#RefereedArticleinInternationalJournal


On Tuesday, May 14, 2002, at 04:45  AM, Blaine Buxton wrote:

> Hello all,
> I was reading Kent Beck's "Guide To Better Smalltalk" and he has an 
> article on Instance-specific behavior in it. In my endivors to get 
> re-acquinted with Smalltalk, I remember doing similiar stuff while 
> debugging windows. Anyway, it looked like a fun little thing to do. SO, I 
> typed in the following in a workspace:
>
> | class |
> class:=Behavior new.
> class superclass: Object methodDictionary: MethodDictionary new format: 
> Object format.
> class compile: 'dodo ^''ya ya'''.
> inst:=class new.
> inst perform: #dodo
>
> If I inspect this, I get the following walkback:
> MessageNotUnderstood: 
> compile:notifying:trailer:ifFail:elseSetSelectorAndNode:
> 13 May 2002 9:25:45 pm
>
> VM: Win32 - Squeak3.2gamma of 12 January 2002 [latest update: #4858]
> Image: Squeak3.2gamma [latest update: #4857]
>
> Behavior(Object)>>doesNotUnderstand:
> 	Receiver: a descendent of Object
> 	Arguments and temporary variables:
> 		aMessage: 	a Message with selector: 
> #compile:notifying:trailer:ifFail:elseSetSel...etc...
> 	Receiver's instance variables:
> 		superclass: 	Object
> 		methodDict: 	a MethodDictionary()
> 		format: 	2
>
> Behavior>>compile:notifying:
> 	Receiver: a descendent of Object
> 	Arguments and temporary variables:
> 		code: 	'dodo ^''ya ya'''
> 		requestor: 	nil
> 		method: 	nil
> 		selector: 	nil
> 		methodNode: 	nil
> 		sel: 	nil
> 		parseNode: 	nil
> 		f: 	nil
> 	Receiver's instance variables:
> 		superclass: 	Object
> 		methodDict: 	a MethodDictionary()
> 		format: 	2
>
> Behavior>>compile:
> 	Receiver: a descendent of Object
> 	Arguments and temporary variables:
> 		code: 	'dodo ^''ya ya'''
> 	Receiver's instance variables:
> 		superclass: 	Object
> 		methodDict: 	a MethodDictionary()
> 		format: 	2
>
> UndefinedObject>>DoIt
> 	Receiver: nil
> 	Arguments and temporary variables:
> 		class: 	a descendent of Object
> 	Receiver's instance variables:
> nil
> --- The rest of the stack ---
> Compiler>>evaluate:in:to:notifying:ifFail:
>
> Is this the correct behavior? (no pun intended). Anyway, so I looked for 
> implementors of: #compile:notifying:trailer:ifFail:elseSetSelectorAndNode:
> . And I got a sole implementor at ClassDescription. So, I replaced 
> Behavior with ClassDescription and voila it works! But, wait...take out 
> the #perform: and do inspect-it on the code so it returns the inst 
> variable. Now, in the inspector, type in the code: 'self perform: #dodo' 
> and print-It. Now, I get a walkback with the following details:
>
> MessageNotUnderstood: classPool
> 13 May 2002 9:32:56 pm
>
> VM: Win32 - Squeak3.2gamma of 12 January 2002 [latest update: #4858]
> Image: Squeak3.2gamma [latest update: #4857]
>
> ClassDescription(Object)>>doesNotUnderstand:
> 	Receiver: a subclass of Object
> 	Arguments and temporary variables:
> 		aMessage: 	a Message with selector: #classPool and arguments: #()
> 	Receiver's instance variables:
> 		superclass: 	Object
> 		methodDict: 	a MethodDictionary(#dodo->a CompiledMethod (2207) )
> 		format: 	2
> 		instanceVariables: 	nil
> 		organization: 	('as yet unclassified' dodo)
>
>
> FakeClassPool class>>adopt:
> 	Receiver: FakeClassPool
> 	Arguments and temporary variables:
> 		classOrNil: 	a subclass of Object
> 	Receiver's instance variables:
> 		superclass: 	Object
> 		methodDict: 	a MethodDictionary()
> 		format: 	2
> 		instanceVariables: 	nil
> 		organization: 	('as yet unclassified')
>
> 		subclasses: 	nil
> 		name: 	#FakeClassPool
> 		classPool: 	nil
> 		sharedPools: 	nil
> 		environment: 	nil
> 		category: 	nil
>
> TextMorphEditor(ParagraphEditor)>>evaluateSelection
> 	Receiver: a TextMorphEditor
> 	Arguments and temporary variables:
> 		result: 	nil
> 		rcvr: 	nil
> 		ctxt: 	nil
> 		ex: 	nil
> 	Receiver's instance variables:
> 		model: 	an Inspector
> 		view: 	nil
> 		sensor: 	an EventSensor
> 		lastActivityTime: 	nil
> 		redButtonMenu: 	nil
> 		redButtonMessages: 	nil
> 		scrollBar: 	0 at 0 corner: 0 at 0
> 		marker: 	0 at 0 corner: 0 at 0
> 		savedArea: 	nil
> 		menuBar: 	0 at 0 corner: 0 at 0
> 		savedMenuBarArea: 	nil
> 		paragraph: 	a NewParagraph
> 		startBlock: 	a CharacterBlock with index 1 and character $s 
> and rectangle 0 at 0 co...etc...
> 		stopBlock: 	a CharacterBlock with index 20 and rectangle 114 at 0 
> corner: 114 at 14
> i...etc...
> 		beginTypeInBlock: 	nil
> 		emphasisHere: 	#(a TextFontChange font: 1)
> 		initialText: 	a Text for 'self perform: #dodo'
> 		selectionShowing: 	false
> 		otherInterval: 	(1 to: 0)
> 		morph: 	a TextMorphForEditView(2968)
> 		oldInterval: 	nil
> 		pivotBlock: 	nil
>
> [] in PluggableTextMorph>>printIt
> 	Arguments and temporary variables:
> 		result: 	nil
> 		oldEditor: 	a TextMorphEditor
>
> --- The rest of the stack ---
> TextMorphForEditView(TextMorph)>>handleEdit:
>
> Now, I do implementors on the classPool method and I get Class and some 
> other classes to be implementors. I change my example from 
> ClassDescription to Class and everything works beautifully! Now, I hate 
> to be long winded to get to my question, but is this the way it is 
> supposed to work? I thought behavior handles the format, methods, 
> compiling, and superclasses. Very minimal. Anyway, it seems 
> ClassDescription and Class are more than I want. Did I just find some 
> bugs? I created a TempBehavior class and implemented classPool (simply 
> returned nil) and compile:etc method (I actually used the 
> ClassDescription implmentation and removed the code that added it to the 
> changes file). This seemed to make the inst work in the inspector and 
> everything seemed to work. Do we need to put these methods up in Behavior 
> or at least abstract implementations?
>
> It seems to me that at any rate, we would want the inspector to be able 
> handle any instances of Behavior and not just Class instances. I'm just 
> asking to make sure I'm not doing something wrong.
>
> FYI, The code was taken pretty much from Kent's book and modified to fit 
> Squeak.
>
> I tried the example in Dolphin too and got a different set of errors.
>
>
> Thanks for your time,
> Blaine Buxton
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos: 
> http://photos.msn.com/support/worldwide.aspx
>
>