How many senders of #methodDict would miss-behave? No risk to throw away a freshly basicAddedSelector:withMethod: ? Or should the IDE be aware of the cannotInterpret: experiments ? Maybe the comment should be (seriously): "When methodDict instance variable of a class is nil, the VM will redirect any message send to an instance by sending the message cannotInterpret: to the receiver but starting the look up in the superclass. NDLR: Or is it to the next superclass having a non nil methodDict? Since most senders of #methodDict message are unaware of this feature, we try to fool them by providing a new empty MethodDictionary in this case, which shall hopefully make them apparently work. Whether undesirable side effect might occur or not, silently or not, is unspecified. Cross your fingers..." Nicolas 2012/2/6 Mariano Martinez Peck <marianopeck@gmail.com>:
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