On 16/07/07, bryce at kampjes.demon.co.uk <bryce at kampjes.demon.co.uk> wrote:
> sig writes:
>  > Another point why i'd prefer to use a single struct (call it foo, or
>  > anything else) for interpreter globals, is to encapsulate all global
>  > values in single place:
>  > - VM variables
>  > - pointers to VM functions.
>  >
>  > And in generated code use foo->bar for values, and foo->bar(...) for
>  > function calls.
>  >
>  > This will give me ability to replace a function pointer with own code
>  > on the fly in running VM, without recompiling code at all.
>  > And moreover, this eliminates the need in having InterpreterProxy
>  > variable for each plugin.
>
> There are two separate questions here:
>  * Should you be able to always use foo?
>  * Should other people be able to not use foo?
>
> In my opinion the ideal answer is yes to both questions.
>
This depends on how well VM infrastructure organized.
In ideal situation, there must be a single global variable
static foo * VM.
This variable can be a pointer to foo struct or simply a value -
depends on if you want  to be able switching between different
interpreters using single executable, as someone suggested.
In current code, foo always assigned to &fum , so its not possible to
switch between different VM's. And semantically using foo->bar is the
same as using fum.bar.
All plugins using InterpreterProxy, and already calling VM functions
indirectly.
I see no big harm to make VM behave similar - call it's functions indirectly.

> Bryce
>
>