[Vm-dev] Re: Method executing but not sent to the receiver

[Igor Stasenko]

On 26 April 2011 18:18, Henrik Sperre Johansen
<henrik.s.johansen at veloxit.no> wrote:
>
> On 26.04.2011 16:31, Mariano Martinez Peck wrote:
>
>
>
>
>
> On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <henrik.s.johansen at 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
>
> 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.
>
> 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?
>
> 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
>
> Cheers,
> Henry
>

-- 
Best regards,
Igor Stasenko AKA sig.