upvar vs fully qualified

What is the reason/advantage of using upvar/global in your procs as
opposed to fully qualifying the variable name?

Example usage:

set x MyVAR

proc test {x} {upvar $x y; set y NewVar}
or
proc test {} {global x; set x NewVar}
or
proc test {x} {set $::x NewVar}
or
proc test {} {set ::x NewVar}

It seems that the last two cases make upvar/global not needed.
Ever since I started learning TCL, the upvar syntax seemed weird to
me. I never got used to it. I never use it in my code but lots of
people do. Is there a good reason for it?

On Apr 1, 11:03=A0pm, vit...@gmail.com wrote:
> Well, makes sense. Although not compelling enough for me to start
> using upvar but I guess it depends on the individual taste. It is
> always possible, I think, to structure your code to never need upvar.

Never seen a callstack deeper than one ?
Please remove the upvar below:

proc myincr vv {upvar $vv v;incr v 2}
proc foo {} {set x 10;myincr x;return $x}
puts [foo]

-Alex

On Apr 1, 8:04 pm, vit...@gmail.com wrote:
> What is the reason/advantage of using upvar/global in your procs as
> opposed to fully qualifying the variable name?

(1) You can't fully qualify a local variable.

(2) You can avoid polluting the global namespace

Twylite

vit...@gmail.com wrote:
> Well, makes sense. Although not compelling enough for me to start
> using upvar but I guess it depends on the individual taste. It is
> always possible, I think, to structure your code to never need upvar.
> Especially if you use XOTcl  for your programming, which I do.

Upvar (and uplevel) are really needed and useful if you try to do some
kinds of metaprogramming like building your own control structures and
stuff like that. Its also needed as a kind of reference to local vars,
e.g. for arrays. But yes, you can work around it most of the time.

Michael

vitick@gmail.com wrote:
> What is the reason/advantage of using upvar/global in your procs as
> opposed to fully qualifying the variable name?
>
> Example usage:
>
> set x MyVAR
>
> proc test {x} {upvar $x y; set y NewVar}
>      or
> proc test {} {global x; set x NewVar}
>      or
> proc test {x} {set $::x NewVar}
>     or
> proc test {} {set ::x NewVar}
>
> It seems that the last two cases make upvar/global not needed.
> Ever since I started learning TCL, the upvar syntax seemed weird to
> me. I never got used to it. I never use it in my code but lots of
> people do. Is there a good reason for it?

As others have said, [upvar] is a different kind of beast from global or
variable. It links a local variable to a variable on the stack. In
particular, it allows you to link to a variable that is local to some
other proc invocation, which no other command lets you do. The main
benefit of this is that it allows you to implement commands that alter
variables in the caller's scope, much like built in commands such as
[incr], [lappend] etc do:

proc add10 varName {
upvar 1 $varName var
incr var 10
}
proc test {} {
set a 1
add10 a
puts "a = $a"
}
test

-- Neil

Yes, all those arguments above do make sense. Another compelling
argument is that the code is slightly faster when you use global,
variable or upvar. Although, running "slightly faster" is never the
first priority to me. I like readable, easy to follow code (probably
"readable and easy to follow to ME" - but that's another issue).  Late
me state my case:

If anyone has ever used XOTcl you would probably know that one of the
useful commands in XOTcl is the "Object" command. Even if you never
learned XOTcl (which is very easy to learn, I wish I did it much much
sooner), and even if you DON'T WANT to learn XOTcl. you SHOULD learn
to use this command.  :) This command does not require knowledge of
XOTcl.

Example:

I am working on an application called WWW (for whatever reason).

I store my variables like this:

[ Object www -requireNamespace ]
set the variable "ip":
[ www set ip 127.0.0.1 ]

print the variable
[ puts [www::ip] ]
or
[ puts [www set ip] ]

pass the variable by name to the proc:
[ www_proc www::ip ]
or, depending on the logic of the application I just pass the name
of the object (www) to my procs.

I can also create arrays in my www object [ www array set ar "name
value" ] and define procs [ www proc tst {} {puts hello} ].

And all of that while not even beginning to deal with classes,
inheritance etc.

"Object" is just an easy and very convenient replacement of
namespace.

The reason I like to use it is to make my code cleaner and and more
readable. (I can't stand the brace maze)
Of course, the code is easier to maintain. I store the application
related vars/arrays/procs there.

Another  trick if you want to do some modifications to your code
but don't want to lose the old code you can do [www copy www1] and use
the "www1" object to test your modifications.

Of course, those are my personal preferences, and many people fill
probably find them awkward, but they work well for me.