[PATCH 1/9] vbscript: Add script TypeInfo stub.

[Gabriel Ivăncescu]

On 10/16/19 4:16 PM, Jacek Caban wrote:
> Hi Gabriel,
> 
> On 10/16/19 1:52 PM, Gabriel Ivăncescu wrote:
>> And the context changes are not reflected by earlier typeinfos, so the 
>> duplication is necessary, each of them is "frozen" at the moment it is 
>> retrieved
> 
> 
> I'm not convinced. Note that we currently store functions and variables 
> in lists and always add new members to the beginning of the list. It 
> means that you may treat each element of the list (head is the most 
> interesting element) as an immutable (or "frozen") snapshot of current 
> context. Storing current head of variables and functions lists in 
> TypeInfo should be enough, AFAICS.
> 

There's several issues with this. First, the script engine itself can be 
closed and released, and in this case, the lists will get released as 
well (the code has asserts about this behavior when the IDispatch 
ScriptDisp gets released). This is why I copy the strings to the 
TypeInfo's pool.

Also, the variables need to be stored in reverse order compared to how 
we compile them, and separated by const/non-const to match Windows in 
terms of their indices. I think this may be important because you can 
use GetVarDesc to retrieve it by index.

BTW, we cannot store a pointer to the head of the list, because we need 
to random-access them in GetFuncDesc/GetVarDesc by index. I also think 
this index must match Windows. Some applications loop through them with 
indices (from 0 up to cVars from the GetTypeAttr). At least creating an 
array is necessary so this process doesn't have non-linear complexity...

> 
> If you need something more sophisticated, it should be possible to 
> change how we store the context in a way that we could retrieve such a 
> snapshot easily. I can imagine compiler storing global functions and 
> variables in a separate collection that is immutable. It would probably 
> have to be recreated whenever something changes (which is rare), but it 
> could be efficiently use across vbscript.
> 

So one giant pool for everything? The problem in this case is, what 
would be the best way to release it properly? We'd need some sort of 
reference counting at the very least, so that releasing the ScriptDisp 
doesn't also release the list if there are any TypeInfos holding it. 
Which would complicate things a bit. Is that something like what you're 
thinking of?

Thanks,
Gabriel