Date: Tue, 30 Jan 2007 17:24:59 +0200
   From: Alexander Rabtchevich <[EMAIL PROTECTED]>

   Raphaël, this IS exactly my point! Why should the global variables
   be prohibited if there is no difference in memory consumption with
   local ones, only additional efforts to a programmer to track all
   parenthesis.  The common namespace is the other problem - it is due
   the luck of interpreter usage or implementation, not the language

   > Also, does it make sense to worry about leaving a variable and
   > its context in memory for a little while when this variable only
   > takes a few bytes and the data that you are manipulating is
   > several orders of magnitude larger?  Keeping an integer and its
   > context on the stack means almost nothing in comparison with the
   > megabytes of image data that the script is processing.

Raphael is quite correct.  Global variables are serious bad juju in
this situation.

The basic problem here is that script-fu runs all scripts in the same
environment.  It isn't invoked separately for each plugin.  This means
that any plugin that uses a global variable without setting it first
(basically, an unitialized variable) is at the mercy of any other
plugin that may have set that variable.  That means that if the
programmer isn't careful the results obtained will depend upon what
happened to be run previously -- in other words, plugins may give
different results depending upon what happened before.

If you're going to initialize all global variables each time you run a
script (which is the only safe thing to do, for the above reason), you
might as well just not use them, since they're effectively going to be
local, anyway.  The first time you have to track down a bug caused by
cross-script global variable pollution will cost you more time than
*all* of the time you spend tracking parentheses on every script you
write in your lifetime, practically guaranteed.

I remember one bug that took me something like 12 hours to find, in
6.001 (the intro programming class at MIT -- taught in Scheme, at
least when I was there).  It was due to a variable in the project code
that was named "exp" that I was somehow picking up (I've long since
forgoten the details -- I fired off an angry and frustrated email to
Sussman and Abelson, and received a prompt apology).  A few of those
will change one's outlook in a hurry.

I won't go so far as to say that global variables should *never* be
used -- just like all good rules, there are exceptions.  A shared
environment that's running many programs without any namespace
separation is one place where there really should *never* be global
variables that the individual programs can use read/write (as opposed
to global read-only variables exported by the environment, which are
safe).  Statically scoped variables would be safe enough; I don't
recall that Scheme supports them (as I recall, everything in Scheme is
supposed to be lexically scoped).

Robert Krawitz                                     <[EMAIL PROTECTED]>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gutenprint   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Gimp-developer mailing list

Reply via email to