Global Variable Namespaces
DonStauffer last edited by 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 last edited by
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 last edited by
@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 last edited by
@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?
@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.