Variable scope

[David Coffey]

In working with TCL procs I find that if I declare a variable as global in one proc a similarly named variable in another proc(same thread) is updated.  In other words using a global variable with the same name in multiple procs in a thread, which ever proc updated the variable last, this is reflected in all other procs.  

How can I set a variable to be global only in the scope of the proc without resorting to unique names in each and every proc in my library?  

Hope this makes sense!

David Coffety

Topic

[Charlie Bursell]

This is true if in the same Tcl interpreter

I suggest you use namespaces

[David Coffey]

Same thread would be the same TCL interp, true?

Can I get a 30 second explanation (if possible) on how I could use namespaces?   Or a link on the interwebs where I can educate myself.

Thanks in advance.

David

[Charlie Bursell]

Simply Google “tcl namespace tutorial” and you will see many.

[Terry Kellum]

If you don’t have it already, I would highly recommend the Brent Welch book “Practical Programming in TCL and TK”.  I have the Fourth Edition.

http://www.amazon.com/Practical-Programming-Tcl-Tk-4th/dp/0130385603

ISBN 0-13-038560-3

There is a whole chapter on Namespaces.

A quick sketch on namespaces with regard to your variable issue is that namespaces provide a hierarchical set of global variable references.

Say we wanted a variable named “common”.  We can put that variable in a namespace for access by any proc that runs in that interpreter.

(In Cloverleaf, each UPOC in an engine has a common interpreter.)

You initialize by using the incantation:

Code:

namespace eval MySpace {
  variable common
}

You can then use the global variable in any of the procs that run in that UPOC thusly,

Code:

set MySpace::common  “MyScalar”

puts $MySpace::common

You can also create procs in namespaces and call them from any downstream proc as well.  They are an indispensable utility for advanced implementation.

I realize that this involves renaming variables, but using namespaces is well worth the investment.

[David Barr]

Can you use message metadata (the USERDATA field) instead of global variables to pass data to the other procs? This would be a lot cleaner.

[Terry Kellum]

You have to.  The interpreters are vertical, not horizontal.

If you want extra-data to go with the message, you have to use metadata fields.  I have used USERDATA before to carry information across the translate to the post-procs.

[David Coffey]

Thank you to everyone who responded to my question.  

In retrospect it is not that complex, though it did take me some time to get to a working model.

David

[Anwar Husain]

I used global associative arrays to store values, for dynamic declaration and assignment.

[Author]

Replies