[Vm-dev] #cannotInterpet: use last class rather than receiver's class?

Eliot Miranda eliot.miranda at gmail.com
Thu Dec 8 17:17:13 UTC 2011


On Thu, Dec 8, 2011 at 9:11 AM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

>
>
>
> On Thu, Dec 8, 2011 at 5:58 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>> Hi Marian,
>>
>> On Thu, Dec 8, 2011 at 7:50 AM, Mariano Martinez Peck <
>> marianopeck at gmail.com> 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?
>

cannotInterpret:, like doesNotUnderstand: only happen as a result of a
send.  The system has to send a message before the VM can send
cannotInterpret:, right?  Specifically cannotInterpret: happens when a send
is made to a receiver where a class in the receiver's hierarchy with a nil
methodDictionary is found before a class with a methodDicitonary containing
the send's selector.  The original send can be a normal send (lookup starts
in receiver's class) or a super send (lookup starts in the superclass of
the method's methodClass).


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

proxies are neither here nor there.  lookupClass contains the class in
which the lookup started.  Following this class's superclass chain *will*
find the class with the nil merhodDictionary since the VM found it.


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


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111208/fffe06d1/attachment-0001.htm


More information about the Vm-dev mailing list