better Behavior>>methodDict

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

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 <[hidden email]>:

> 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 <[hidden email]>:
>>>
>>>
>>> On Mon, Feb 6, 2012 at 10:17 PM, Stéphane Ducasse
>>> <[hidden email]> 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
>>>
>>
>
>

On Wed, Feb 8, 2012 at 4:04 PM, Nicolas Cellier <[hidden email]> wrote:

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

Even if the real motivation is hackish, I am not copletly sure that this solution is negative. It somehow can be seen as the "null pattern" and avoid checking for #isNil all the time. Apart from that, I think this "pattern" is already present in Pharo, like:

Class >> subclasses
    "Answer a Set containing the receiver's subclasses."

    ^subclasses == nil
        ifTrue: [#()]
        ifFalse: [subclasses copy]

 

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

True. But I guess if someone is using #cannotInterpert: then it is someone who really understand the consequences.

But it is not bad to mention it anyway ;)
 

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.

Better proxy implementations.

 

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 <[hidden email]>:

> 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 <[hidden email]>:
>>>
>>>
>>> On Mon, Feb 6, 2012 at 10:17 PM, Stéphane Ducasse
>>> <[hidden email]> 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
>>>
>>
>
>

--
Mariano
http://marianopeck.wordpress.com