#92 RootTable Prop/StaticVar?

[Spruce]

I'd like a way to bind non-class types (bool/int/float/etc) to the RootTable and have the changes propagate between C++ and the script, so when the variables change C++ side, the script will reflect that change

There is currently no way to bind a C++ global variable of non-class type (bool/int/float) to the RootTable and have that variable reflect changes that the script or C++ makes to that variable:
-RootTable SetInstance reflects changes but only works on class types (no bool,int,float)
-RootTable SetValue does not take a reference and can't reflect changes to/from C++

- There is no GlobalProp / StaticVar for the RootTable(Sqrat::Class have them though)

+Can the RootTable be made to support GlobalProp and StaticVar?

Does this require a modification to the scripting language's VM, or can Sqrat be made to support this?:

RootTable StaticVar:

bool globalvalue = true;
...
{
    Sqrat::RootTable(vm).StaticVar("globalvalue", &globalvalue);
}

---

RootTable Global Prop (get/set):

bool getvalue() { return globalvalue; }
void setvalue(bool v) { globalvalue = v; }
...
{
    Sqrat::RootTable(vm).GlobalProp("globalvalue", getvalue, setvalue);
}

---

Then in the script, the RootTable binding would allow globalvalue to be accessed like a variable (similar to Sqrat::Class GlobalProp/StaticVar):

// get 'globalvalue' without using () function call, or needing Namespace.
print(globalvalue);

// set - the change will be visible C++ side
globalvalue = false;

[Wizzard]

I was thinking about this issue today, and decided it shouldn't be implemented in Sqrat.
The reason is because this would involve editing the metatable for the root table.
Since Sqrat does not create the root table, I don't think that it should control its metatable.
If it did, then people whom overwrite the metatable themselves would need some workaround.
The workaround could be something like Sqrat::RootTable(vm)::OverwriteMetaData.
OverwriteMetaData would have to be called before being able to use GlobalProp for root table.
However, I think this is messy and really uncessary because workarounds exist.
It's probably better to create and bind a Settings class to the root table as an instance.
From this instance, you could do something like settings.globalvariable for the syntax.