I'm working on a Tcl-Tk project and have some namespaces. But the main part (the one for the main window and settings, which affect the whole program) is at the moment in the global namespace. I'm now wondering what is the best way for variables in the global namespace:
proc TestVariable {} {
global MyVar
variable MyVar
...
}
When TestVariable is in global namespace, both variants would achieve the same result. Am I correct? If this is the case, which variant is the better one to use?
Global variables are namespace variables in the global namespace. The global namespace is slightly special, in that it is where things appear from by default in other namespaces; this is what you want with commands (and what you REALLY don't want with variables, which is why you should declare namespace variables with the variable command).
In general, it's best to keep the global namespace for things that belong to the application overall, and put anything with more restricted applicability in some other namespace. If you're writing library code, absolutely put it in a namespace (often with the same name as the library package). That prevents much confusion.
You should restrict yourself to use large number of global variables. It is always a good idea to use namespace for defining the variables.
Check "http://tcl.tk/man/tcl8.5/tutorial/Tcl13.html". This will provide you some insight and also check "http://tcl.tk/man/tcl8.5/tutorial/Tcl31.html" for more details
Related
I have been reading about namespaces in TCL. I was trying to understand the structure of namespaces (using some sort of venn diagrams) in TCL but as i read more articles on the internet , they add to my confusion.
What i am certain about at this stage is that there is one global scope and , one local scope for procedures.
Can anyone throw some light on how namespaces are arranged in TCL or provide some good articles to read.
Thanks
They are similar to absolute and relative filepaths on a computer disk. Think of a tree instead of a Venn diagram.
The :: is a namespace separator just like a / is a path separator in a Linux file system.
A namespace starting with :: is an absolute namespace, just like a file path starting with / is an absolute filepath.
A namespace not starting with :: is a namespace relative to the current namespace, just like a filepath not starting with / is a relative filepath.
The Tcl global namespace, ::, is at the top of the tree, just like / is at the top of a Linux file system.
Tcl namespaces can have child namespaces and will have a parent namespace (unless it's the global namespace).
Namespaces are named collections in Tcl. They can effectively have three things in them: commands, variables and other namespaces (forming a tree). The things that they contain can all be looked up by name. Namespaced names use :: as a separator, much like / and/or \ are directory name separators (depending on your platform).
There is always a global namespace (usually called :: because the empty string is more awkward to work with) and recent versions of Tcl have a few others (notably ::tcl and ::oo). The global namespace is unique per interpreter; other interpreters have their own global namespace. There isn't anything that's a parent of the global namespace.
Namespaces have one other major trick: like a procedure stack frame, they can be pushed onto the stack. (Conceptually they're both instances of an abstract pushable thing, except we don't implement things that way.) Note that procedure stack frames are always associated with a current namespace which they use to look up the names of commands (and which the variable command looks up variables in). That current namespace is also where proc makes procedures and where the create method of classes makes instances, in both cases provided the name given is unqualified (or relative).
There are some additional complexities, but basically they're just the holders of all the main named entities in Tcl.
I'm using reagent to build several alternate root components, only one of which will be mounted on any given page; definitely either/or. These have a degree of commonality in their makeup, hence it will be convenient to move what is common among them to a common namespace.
What would be ideal is if in the file for each of these components I had the option to switch namespace into common, and add defs particular to the component, then switch back, thus avoiding circular dependencies nor needing any kind of inheritance.
I recalled this being possible in common lisp, how wonderful it was, and it also seems possible in clojure.
From Clojurescript docs: ns must be the first form and can only be used once, and in-ns is only usable from the repl.
I'm wondering if there's a way to achieve this kind of thing in clojurescript which is still eluding me.
If not I may need to reconsider my assumptions behind multiple alternate root components; the "many builds within one build" kind of idea, if that makes sense.
Update after some futher experimentation and confusion:
another option might be to split a single namespace across multiple files (is this possible?). Not sure what direction to turn in here.
The fact that in reagent I am using atoms in the global namespace is what's creating the need for circular dependencies if I use a separate namespace for common. Hence, wonder about one global namespace, in which case multiple files might help. Or is the way forward one giant file and one namespace??
Update: I've realised there is a great tension between keeping all app state globally (in my current case, multiple atoms), and passing app state around. My pattern currently is everything global, don't pass any of it around. Passing the necessary state as parameters to fns in the common namespace would solve the problem here (duh!), but then there's the question of what principles are being followed here regarding app state. If I just added a param whenever I needed one, but started with the idea that everything was global, there'd be no real principle to it...
In ClojureScript, everything is pre-compiled into a single static JavaScript "executable", so there is nothing like the repl you are used to in Clojure. Indeed, in CLJS the "Var" concept doesn't really after the compiler, they are just static (constant) variables and cannot be rebound.
Having said that, CLJS does emulate the behavior of Clojure dynamic variables via the binding form, so that may help you to reach your goal. As in CLJ, it creates what amounts to a (thread-local) global variable. This is a degenerate case in CLJS since there is only one thread. However, the source code looks identical to the CLJ case.
Another way to accomplish this is to just use a plain atom as a global variable so you don't have to pass a parameter around.
As always, when using a global variable, it reduces the number of parameters in function call trees, but it creates invisible dependencies between different parts of the code. Somethimes convenient, but usually a bad tradeoff.
I have a UVM testbench that uses configurations to replace a VHDL component that is deep within the design. Each test that I create has to use a verilog configuration to replace that component. Is there a way to use a variable for the hierarchical path so that I don't have to update each configuration if the VHDL design changes?
There is no way to use a variable to represent a hierarchical path, except for virtual interface variables used to represent the hierarchical path to interface instances.
You will need to show use an example of how each test changes the VHDL component to give us a better idea for a solution; maybe you can use a macro.
I found a solution that does what I would like it to do. I have used macros to define the instances that I want to configure. The following is a an example of what I have done:
`define USE_TB_COMP instance top.u_mod1.u_sub_mod1.u_comp use tb_comp;
config test1_c;
`USE_TB_COMP
endconfig
config test2_c;
`USE_TB_COMP
endconfig
....
I've been looking at some Lua source code, and I often see things like this at the beginning of the file:
local setmetatable, getmetatable, etc.. = setmetatable, getmetatable, etc..
Do they only make the functions local to let Lua access them faster when often used?
Local data are on the stack, and therefore they do access them faster. However, I seriously doubt that the function call time to setmetatable is actually a significant issue for some program.
Here are the possible explanations for this:
Prevention from polluting the global environment. Modern Lua convention for modules is to not have them register themselves directly into the global table. They should build a local table of functions and return them. Thus, the only way to access them is with a local variable. This forces a number of things:
One module cannot accidentally overwrite another module's functions.
If a module does accidentally do this, the original functions in the table returned by the module will still be accessible. Only by using local modname = require "modname" will you be guaranteed to get exactly and only what that module exposed.
Modules that include other modules can't interfere with one another. The table you get back from require is always what the module stores.
A premature optimization by someone who read "local variables are accessed faster" and then decided to make everything local.
In general, this is good practice. Well, unless it's because of #2.
In addition to Nicol Bolas's answer, I'd add on to the 3rd point:
It allows your code to be run from within a sandbox after it's been loaded.
If the functions have been excluded from the sandbox and the code is loaded from within the sandbox, then it won't work. But if the code is loaded first, the sandbox can then call the loaded code and be able to exclude setmetatable, etc, from the sandbox.
I do it because it allows me to see the functions used by each of my modules
Additionally it protects you from others changing the functions in global environment.
That it is a free (premature) optimisation is a bonus.
Another subtle benefit: It clearly documents which variables (functions, modules) are imported by the module. And if you are using the module statement, it enforces such declarations, because the global environment is replaced (so globals are not available).
What exactly is global data?
This may seem like a very rudimentary question but the reason I'm asking is because I'm wondering has the term become stretched over time - i.e it dosn't just apply to data in the "Global" namespace (in c++) or a variable that is available in every scope.
So, what do you consider to be global data?
I agree David, global can quite often mean different things to different people in different languages!
Personally I hate globals which are truly global, i.e. available to everything, everywhere. The greater the restriction of a scopes' variable, generally the better.
The scope of the information often has to be open to lots of functions within a module, this is OK, but should be limited where required. These I would define a module globals or local globals.
Variables which are shared between modules through a defined interface and only included as required are OK-ish, but data passed back and forth (or pointers to data) from/to functions are the best.
Of course, this is all my personal opinion in my native language (C) and might not agree with everyone's opinion!
Global data is a variable that can be put in any local scope (i.e. of a function) without passing it as a parameter or class attribute.
In some languages you need a global or extern keyword to import it, in others it enters the function's scope automatically.