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