Unpopularity of global variables - why?

Peter Haworth pete at lcsql.com
Fri Oct 12 16:24:33 CDT 2012


What Mark said.  Plus I've spent many a happy hour debugging code that was
supposed to refer to a global variable except that I forgot to declare it
as such in my script so it was treated as a local variable (in the days
before realising that Strict Compile Mode is a good thing to do).  That's
my own stupidity of course but any time I find a way to protect myself from
my own mistakes, I'll take it!

Pete
lcSQL Software <http://www.lcsql.com>



On Fri, Oct 12, 2012 at 1:50 PM, Graham Samuel <livfoss at mac.com> wrote:

> The discussion about Strict Compile Mode brought in a lot of stuff about
> globals, and I sense that many people think they're a bad thing - I am not
> talking about trick ways of using them, just regular globals that allow one
> to refer quantities (numbers, strings, anything really) across scripts
> which are housed in different objects in the same program (set of stacks).
>
> The thing is, I can't see the objection. Clearly any technique can become
> sufficiently messy and obscure as to negate its own usefulness, but what's
> wrong with the idea itself? If I want to maintain for example a status
> across a whole program, if I don't use a global, I am going to have to use
> a custom prop or a function to transmit that status across object
> boundaries, and that means more typing with no more security, so why do it?
> What's wrong with
>
>    if gMy_Status is "open"...
>
> compared to
>
>    if fMy_Status() is "open"…
>
> or
>
>    get the cpMy_Status of stack "myStack"
>    if it is "open"…
>
> Again, since the 'constant' command doesn't have global status, what's
> wrong with using globals to store program-wide constants? Is any other way
> cleaner?
>
> Obviously I'm missing the point - I know I am. It's probably my age. But
> I'd like to see a more reasoned attack on globals before I give them up.
>
> Graham
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


More information about the use-livecode mailing list