Re: changes in script-fu in 2.3.14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



   Date: Tue, 30 Jan 2007 17:24:59 +0200   From: Alexander Rabtchevich <alexander.v.rabtchevich@xxxxxxxxxxxxxxx>
   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   itself.
   > 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 inthis situation.
The basic problem here is that script-fu runs all scripts in the sameenvironment.  It isn't invoked separately for each plugin.  This meansthat any plugin that uses a global variable without setting it first(basically, an unitialized variable) is at the mercy of any otherplugin that may have set that variable.  That means that if theprogrammer isn't careful the results obtained will depend upon whathappened to be run previously -- in other words, plugins may givedifferent results depending upon what happened before.
If you're going to initialize all global variables each time you run ascript (which is the only safe thing to do, for the above reason), youmight as well just not use them, since they're effectively going to belocal, anyway.  The first time you have to track down a bug caused bycross-script global variable pollution will cost you more time than*all* of the time you spend tracking parentheses on every script youwrite in your lifetime, practically guaranteed.
I remember one bug that took me something like 12 hours to find, in6.001 (the intro programming class at MIT -- taught in Scheme, atleast when I was there).  It was due to a variable in the project codethat was named "exp" that I was somehow picking up (I've long sinceforgoten the details -- I fired off an angry and frustrated email toSussman and Abelson, and received a prompt apology).  A few of thosewill change one's outlook in a hurry.
I won't go so far as to say that global variables should *never* beused -- just like all good rules, there are exceptions.  A sharedenvironment that's running many programs without any namespaceseparation is one place where there really should *never* be globalvariables that the individual programs can use read/write (as opposedto global read-only variables exported by the environment, which aresafe).  Statically scoped variables would be safe enough; I don'trecall that Scheme supports them (as I recall, everything in Scheme issupposed to be lexically scoped).
-- Robert Krawitz                                     <rlk@xxxxxxxxxxxx>
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxxxxxxxxx lead for Gutenprint   --    http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."--Eric Crampton_______________________________________________Gimp-developer mailing listGimp-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux