Global Variable Namespaces

DonStauffer

If I have a system of macros which uses certain global variable names, and someone else develops a different system of macros which incidentally has some global variable names in common with the other, if they're both on the same machine they could conflict due to the persistent nature of global variables. Namespaces would also be potentially useful for displaying and even manipulating groups of variables. Current syntax could be preserved by assuming the existance of a default namespace if none is specified. Naturally, namespace names could potentially conflict, but that's more manageable. One could simulate namespaces by prepending a string to variable names, at the expense of being verbose, and not having the basis for automatic categorization (in the web interface's display of the object model, for example). Avoiding verbosity might imply some mechanism to avoid a macro needing to fully-qualify variable names.

A "Set Namespace" meta-command would be adequate in most situations, I think. Perhaps even in all situations. I could imagine the object model's "global" (maybe being replaced by or put inside a "user" object), containing the name of the current namespace, plus all the globals in the default namespace, and a container for each namespace containing the globals in that namespace.

o_lampe

@donstauffer
would you implement a "foreign" macro without inspecting it beforehand? I wouldn't and I'd use 'speaking' -meaningful names for it's variables. The risk of a conflicting name is minimal IMHO.

gloomyandy

@donstauffer Go "old school" and create your own namespace by prefixing all of your global variables with some sort of identifier, very unlikely you will get a clash then.

DonStauffer

@gloomyandy I addressed the shortcomings of prepending to variable names. And when you say "a" foreign macro: I've written a powerful and useful utility that consists of probably over 300 macros. And "inspecting" it isn't the point. A naming conflict is a naming conflict. Inspect it, find it, and either you have to do potentially extensive modifications, maybe to other people's code, or don't use it.

If these were solutions, wherefore namespaces in other languages?

dc42

@donstauffer I wasn't expecting "programs" written using GCode meta commands to reach the size and complexity of programs written in languages that support namespaces, such as C++.

The C language is very widely used for embedded software development (not by me!) and doesn't support namespaces yet.

I could add support for declaring variables like this:

global myNameSpace.myVar = value;

but that isn't significantly different from this:

global myNameSpace_myVar = value;

Perhaps we need a convention that people developing macros that use global variables and are intended to be portable to other machines use an appropriate prefix in all global variable names.

egmrudd

I have this issue too, but my work around is I have sub directories in the sys directory that have their own config.g and other sys files. When I want to switch configs, I have macros that run M505 "0:\sys\config1" or M505 "0:\sys\config2", etc. I have global variables that get reused in each, like probeLocation, but it gets redifined depending on which config.g is run.

You will also have to run this code block to check if the variable already exists and act accordingly... yeah, yeah I know, the elif is not necessary in this case, I just like being as explicit as possible
edit: converted code from text to embedded code block

;create local variable that is stored until the existence of a global variable is checked


var probeLocationX = XX.XX
var probeLocationY = YY.YY
var probeLocationZ = ZZ.ZZ

if exists(global.probeLocationX) == true
    set global.probeLocationX = {var.probeLocationX}
    set global.probeLocationY = {var.probeLocationY}
    set global.probeLocationZ = {var.probeLocationZ}

elif exists(global.probeLocationX) == false
    global probeLocationX = {var.probeLocationX}
    global probeLocationY = {var.probeLocationY}
    global probeLocationZ = {var.probeLocationZ}