[Pharo-project] 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 Stef
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
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
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
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
On Wed, Feb 8, 2012 at 4:04 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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 <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
-- Mariano http://marianopeck.wordpress.com
On Wed, Feb 8, 2012 at 6:08 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Wed, Feb 8, 2012 at 4:04 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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.
Moreover, such developer can use #methodDict: later on if desired and hence the ability to modify the behavior comes back
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 <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
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
participants (4)
-
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse -
Stéphane Ducasse