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
>>>
>>
>
>