my 2 cents.
the method should be like that:
Behavior>>methodDict
^ methodDict
the tools should be aware that it is low-level accessor and result can be nil.
Or use higher-level accessors provided by Class api (like #selectors
etc) to avoid hacky coding.
On 9 August 2013 14:33, Clément Bera <[email protected]> wrote:
> Hello Mariano and others,
>
> In Pharo there is a method:
>
> Behavior>>methodDict
> methodDict == nil ifTrue: [^ MethodDictionary new ].
> ^ methodDict
>
> It seems (according to the latest author) that it is Mariano who changed it
> from:
>
> Behavior>>methodDict
> methodDict == nil ifTrue: [self error: 'MethodDict is nil'].
> ^ methodDict
>
> A comment is present:
>
> "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 of the class whose method dictionary was nil.
> Now the system relies that when the message methodDict is sent to a class a
> method dictionary is returned. In order to prevent the complaints of tools
> and IDE unaware of this feature, we fool them by providing an empty
> MethodDictionary. This will hopefully work in most cases, but the tools will
> loose the ability to modify the behavior of this behavior. The user of
> #cannotInterpret: should be aware of this."
>
> Now my problem is when I do:
>
> MyClass methodDict: nil.
> MyClass new name.
>
> It crashes the image in latest Pharo 3.
>
> Mariano, do you have an idea on how to fix it ? I ask you because you are
> the latest author and it seems tat the bug comes from this method.
>
> Thanks for any answer.
--
Best regards,
Igor Stasenko.