On 26 April 2011 18:18, Henrik Sperre Johansen email@example.com wrote:
On 26.04.2011 16:31, Mariano Martinez Peck wrote:
On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen firstname.lastname@example.org 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
yup, instvar access in byte codes is indexed.
Nevertheless, exactly the same happens with #valueWithReceiver:arguments: so...ok, we have this problem but we also have from before ;) right ?
Dunno, I only commented on the code you posted.
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.
Not sure if the overhead of such a check would be worth it. The least restrictive to avoid outright crashing would probably be to check that instvar accessing bytescodes in the method did not exceed that of the receiver, but a class check would probably be simpler.
I'd be ok with just a good comment, one would expect users of this to sort of know what they are doing. On the other hand, you didn't realize it untill I pointed it out specifically ;)
If it should be allowed at all, as per Igor's post.
For good or bad, but all methods in system are bound to specific class. After installing a method to class, they can be executed only for (sub)instances of that class. For rest of the cases we have closures, which can be evaluated at any point , based on whatever criteria you may need.
I think that most of the tools will be seriously confused when they will find out some context which has a method which are not belong to one of the (super)class of receiver. This is on top of security issues , which you have to deal with, when using such primitive.
I love disagreeing with myself :D