On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:

Say you have Class A:
inst vars : one two three

and method compiled on it:
foo
^one

Then you also have Class B:
inst vars: three two one

Then you do
methodFoo := A >> #foo
methodFoo executeWithReceiver: B new one: 1; three: 3; yourself arguments:
#()

It'll return 3, which'll probably confuse those not very familiar with the
bytecodes.

Or using a class with no instvars, it'll crash in a similar manner to what
you get if you currently do:
Test methodDictionary at: #foo put: MCPackage >> #packageInfo.
Test >> #foo.
Test new foo

You see, now I got it :)  I am just slow.
Thanks Henrik for this example. In fact, it was not even obvious for me until you told me. The "problem" is that the bytecodes to access/set instanceVariables work by position instead of name, no?
I mean, 'one' is never put in the literals of A >> #foo

Nevertheless, exactly the same happens with #valueWithReceiver:arguments:    so...ok, we have this problem but we also have from before ;)
right ?

solutions?

First I would put a nice comment in #valueWithReceiver:arguments:   and #valueWithReceiver:arguments: 

Second, if I understood you correctly you mean to do in your previous email, you want to validate that the class of the receiver is the same as the class where the CompiledMethod is installed and if it is not, throw an error ?

On the one hand that would limit a bit the usage because that fails only when there is instance var access, doesn't it?  On the other hand, it prevents some crashes or weird cases where the results are not the expected ones.

Opinions?