#cannotInterpet: use last class rather than receiver's class?

 
Hi guys. When the finds a methodDict in nil during the method lookup, it sends #cannotInterpret: to the receiver, but starting the methodLookup in the superclass of the class whose method dict was nil.
Example, if I have A subclass from B and B has the method dict in nil, if I sent #foo to an instance of A, it will send #cannotInterpret: to such instance but starting the method lookup (of the #cannotInterpret:) in B (the superclass).

Now, when sending #cannotInterpret:  aMessage, it sends as parameter an instance of Message. The thing is that in the instVar "lookupClass" it puts the receiver's class. In this example, A. But when you are implementing #cannotInterpret:  such info (the lookupClass) is already there, because you DO have the receiver (in self), so you could always do a "self class". In my case, for some proxies I am doing, I would need not the lookupClass, but the class whose methodDict was nil, in this case, B.

So, questions:

1) Do I break something if I do this?  Am I limiting the solution somehow? it is not always true that I can get the lookupClass while doing "self class" ?  is there someone using this hook of #cannotInterpret:?

2) Ok, I know that I should send an instance of Message with something it is not the lookupClass in the instVar 'lookupClass', but it is a lookupClass in some form ;)

Thanks in advance,

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

 
Hi Marian,

On Thu, Dec 8, 2011 at 7:50 AM, Mariano Martinez Peck <[hidden email]> wrote:

 
Hi guys. When the finds a methodDict in nil during the method lookup, it sends #cannotInterpret: to the receiver, but starting the methodLookup in the superclass of the class whose method dict was nil.
Example, if I have A subclass from B and B has the method dict in nil, if I sent #foo to an instance of A, it will send #cannotInterpret: to such instance but starting the method lookup (of the #cannotInterpret:) in B (the superclass).

Now, when sending #cannotInterpret:  aMessage, it sends as parameter an instance of Message. The thing is that in the instVar "lookupClass" it puts the receiver's class. In this example, A. But when you are implementing #cannotInterpret:  such info (the lookupClass) is already there, because you DO have the receiver (in self), so you could always do a "self class". In my case, for some proxies I am doing, I would need not the lookupClass, but the class whose methodDict was nil, in this case, B.

Not quite.  It puts the lookup class in the lookupClass inst var.  So if a super send invokes cannotInterpret: lookupClass will hold the superclass of the method in which the send occurred.

So, questions:

1) Do I break something if I do this?  Am I limiting the solution somehow? it is not always true that I can get the lookupClass while doing "self class" ?  is there someone using this hook of #cannotInterpret:?

I have no idea.  But given the lookupClass it is a simple matter to walk the hierarchy starting at lookupClass, looking for the first nil methodDictionary.  This will be the class at which cannotInterpret: was initiated.  Isn't this enough?

 

2) Ok, I know that I should send an instance of Message with something it is not the lookupClass in the instVar 'lookupClass', but it is a lookupClass in some form ;)

Thanks in advance,

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

--
best,

Eliot

 

On Thu, Dec 8, 2011 at 5:58 PM, Eliot Miranda <[hidden email]> wrote:

 
Hi Marian,

On Thu, Dec 8, 2011 at 7:50 AM, Mariano Martinez Peck <[hidden email]> wrote:

 
Hi guys. When the finds a methodDict in nil during the method lookup, it sends #cannotInterpret: to the receiver, but starting the methodLookup in the superclass of the class whose method dict was nil.
Example, if I have A subclass from B and B has the method dict in nil, if I sent #foo to an instance of A, it will send #cannotInterpret: to such instance but starting the method lookup (of the #cannotInterpret:) in B (the superclass).

Now, when sending #cannotInterpret:  aMessage, it sends as parameter an instance of Message. The thing is that in the instVar "lookupClass" it puts the receiver's class. In this example, A. But when you are implementing #cannotInterpret:  such info (the lookupClass) is already there, because you DO have the receiver (in self), so you could always do a "self class". In my case, for some proxies I am doing, I would need not the lookupClass, but the class whose methodDict was nil, in this case, B.

Not quite.  It puts the lookup class in the lookupClass inst var.  So if a super send invokes cannotInterpret: lookupClass will hold the superclass of the method in which the send occurred.

Sorry Eliot I couldn't follow you. I don't understand " if a super send invokes cannotInterpret: ". The #cannotInterpret: is only sent by the VM. How do I exactly could do a super send that invokes #cannotInterpret:  ?    In this example I did with A and B how should that happen?

 

So, questions:

1) Do I break something if I do this?  Am I limiting the solution somehow? it is not always true that I can get the lookupClass while doing "self class" ?  is there someone using this hook of #cannotInterpret:?

I have no idea.  But given the lookupClass it is a simple matter to walk the hierarchy starting at lookupClass, looking for the first nil methodDictionary.  This will be the class at which cannotInterpret: was initiated.  Isn't this enough?

 

Good idea. It *may* work. I have to see some weird scenarios with the proxies, but I will give it a try, maybe it can work. Thanks for the idea!

 

2) Ok, I know that I should send an instance of Message with something it is not the lookupClass in the instVar 'lookupClass', but it is a lookupClass in some form ;)

Thanks in advance,

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

--
best,

Eliot

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