On Mon, Feb 6, 2012 at 10:17 PM, Stéphane Ducasse <Stephane.Ducasse@inria.fr
wrote:
Hi mariano
I have the impression that methodDict should be redefined as you propose it because else it does not work well with the cannotInterpret hook. I suggest to redefine methodDict as follow. notice the cool comment!!! If this is ok -> open a bug entry.
Behavior >> methodDict "The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system."
methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict
For me that's perfect and avoids an override in my code :) Maybe we can do: Behavior >> methodDict "The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system." methodDict == nil ifTrue: [^ self manageMDFault ]. ^ methodDict Behavior >> manageMDFault ^ MethodDictionary new That way subclasses can change it without needing an override. but both solutions are fine with me. Other opinions? -- Mariano http://marianopeck.wordpress.com