I think that my first proposition was more a negative speculation than a really useful comment. It was more to emphasize the hackish nature of this change than to help future readers ;) If you really want to include this change, I think you shall mention the true purpose of this hack, and I guess this would be something like: "In order to prevent the complaints of tools and IDE unaware of this feature, we try to fool them by providing an empty MethodDictionary." Eventually, you could mention your expected outcomes: "This will hopefully work in most cases, but the tools will loose the ability to modify the behaviour of such class." Of course, I don't know the context into which you want to use cannotInterpret: so it is hard to tell if the system deserve such hack. I guess you might also add a message stating whether the class is subject to such cannotInterpret: hook or not, maybe something like Behavior>canInterpret "If methodDict instance variable is nil, this Behavior cannot interpret any message. In this case, every message sent to my instances will be redirected to a cannotInterpret: send, starting look-up at etc..." ^methodDict notNil Nicolas 2012/2/8 Stéphane Ducasse <stephane.ducasse@inria.fr>:
mariano can you add a bug entry and we integrate it.
Stef
On Feb 7, 2012, at 1:00 AM, Nicolas Cellier wrote:
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