[PATCH v2 1/8] vbscript: Unlink the code list from the script dispatch when it's released.

[Gabriel Ivăncescu]

On 10/30/19 4:52 PM, Jacek Caban wrote:
> On 10/30/19 3:33 PM, Gabriel Ivăncescu wrote:
>> Hi Jacek,
>>
>> On 10/30/19 4:20 PM, Jacek Caban wrote:
>>> Hi Gabriel,
>>>
>>>
>>> This patch adds extra complexity for unlinking. However, I imagine 
>>> that once you change the representation of global functions and 
>>> variables, they will not be needed. We'd probably need such list 
>>> inside vbscode_t, but it will never be linked/unlinked to a global 
>>> list (global list will in fact not exist).
>>>
>>>
>>> I would expect that it would be easier to first replace lists with 
>>> arrays inside script_ctx_t and consider moving things to script 
>>> dispatch later.
>>>
>>>
>>> Thanks,
>>>
>>> Jacek
>>>
>>
>> Sorry I'm not sure I understand. vbscode_t already stores the list of 
>> its own global variables and functions.
>>
>> They just get linked to the script_ctx_t lists when they are being 
>> executed (after this patch series, now it's when they are compiled 
>> which is wrong).
>>
>> The only alternative I can think of is to copy the variables/functions 
>> over when adding them to the context/dispatch globals. Unlinking them 
>> is, IMO, simpler than copying but that's just me.
>>
>> If we replace them with arrays this won't really change the fact we'll 
>> have to make copies. Is that what you have in mind?
> 
> 
> Now I'm confused, you wanted them to be arrays because of ITypeInfo 
> requirements from the beginning. Your later tests confirmed that it may 
> be a good idea, so I assumed that that's your plan. Arrays could be just 
> store pointers to existing structs, so no copying is required (although 
> we may want to copy some parts of them for a different reason).
> 
> 
> Jacek
> 

Ah yes indeed you are absolutely right. I was thinking that such pointer 
indirection wasn't desirable, for some reason. But if that's good to go 
then I'll implement them that way, then.