[PATCH v8 1/3] jscript: Lookup and ref the named item's dispatch first, during interpretion.

[Jacek Caban]

On 12.03.2020 14:29, Gabriel Ivăncescu wrote:
> Hi Jacek,
>
> On 12/03/2020 13:02, Jacek Caban wrote:
>> Hi Gabriel,
>>
>>
>> On 11/03/2020 14:06, Gabriel Ivăncescu wrote:
>>> @@ -2995,6 +3008,8 @@ HRESULT exec_source(script_ctx_t *ctx, DWORD 
>>> flags, bytecode_t *bytecode, functi
>>>               hres = create_named_item_script_obj(ctx, 
>>> bytecode->named_item);
>>>               if(FAILED(hres)) return hres;
>>>           }
>>> +        if(variable_obj == ctx->global)
>>> +            variable_obj = bytecode->named_item->script_obj;
>>
>>
>> This could be a separated patch. If in this case caller can't handle 
>> variable_obj in many cases, maybe it shouldn't handle it at all. It 
>> seems to me that we could get rid of that argument. exec_source has 
>> all information needed to handle it by itself.
>>
>>
>> Thanks,
>>
>> Jacek
>>
>
> I can split it of course, but I have some doubts when it comes to 
> removing it. What should we do in function.c's InterpretedFunction_call?
>
> A possible solution I came up with would be to add a new exec_flag, 
> say EXEC_NEW_VARIABLE_OBJ and use it in InterpretedFunction_call -- 
> then create it in exec_source if the flag is set.


Unless I'm missing something, a new variable object is needed always for 
non-global non-eval code. You don't need a new flag for that.


>
> In rest of cases, we take the frame->variable_obj if a frame is 
> available, otherwise the ctx->global or named item's dispatch. All of 
> this in exec_source of course, then we get rid of the parameter 
> altogether.
>
> Does that sound like a good approach?


Sounds good, yes.


Thanks,

Jacek