defining and using globals in an application

[Pete]

I opted to go with a combination of the the accessor route as described by
Richard and the array approach described by Stephen.  I have changed the
format of both the array and the contents over time and, as Richard pointed
out, all the code changes to deal with that were limited the Setxxx and
Getxxx  handlers plus the handler that sets up the global values, no change
to the rest of my code.

I use custom properties a lot as well but I use them to store values which
are specific and unique to the function of an object which I don't need to
preserve across runs of an application.  I'm definitely biased because I
tend to work with database applications more than any others but my feeling
is that data that needs to be preserved across runs of an application should
be stored in some sort of database or file external to the application.

All these methods work, it's just a case of which feels more comfortable and
fits your programming style.


Pete
Molly's Revenge <http://www.mollysrevenge.com>




On Thu, Jul 7, 2011 at 6:38 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

> Mark Stuart wrote:
>
>> You HAVE to declare the global again, and again where needed.
>>
>> I'd rather it once declared and a value put into it, the value be
>> available
>> elsewhere WITHOUT having to declare it again.
>>
>
> As Jacque pointed out, LC and related dialects are very forgiving with the
> scope of variable names, so it's possible to have one token used as a
> global, a local, and an argument.  To avoid confusing the compiler, we need
> to declare globals in any script that uses them.
>
> If that one line of code at the top of a script is cumbersome (and in some
> complex code bases it may well be), try accessors instead:
>
> -- In a mainstack, library, backscript, or other globally-available
> -- script:
> global gDefaultWidgetHeight
>
> command SetDefaultWidgetHeight pVal
>  put pVal into gDefaultWidgetHeight
> end SetDefaultWidgetHeight
>
> function GetDefaultWidgetHeight
>   return gDefaultWidgetHeight
> end GetDefaultWidgetHeight
> ---
>
> With those in place you can get and set the value stored in the global from
> any other script without a declaration, e.g.:
>
>  set the height of grp 1 to GetDefaultWidgetHeight()
>  SetDefaultWidgetHeight 200
>
> Another benefit to using accessors is that they help factor code; that is,
> you can change how you store that value at any time without having to modify
> any code that relies on it.  Today it might be a global, but two versions
> from now it might be a database record; with accessors, you only change two
> handlers and everything else comes along for the ride.
>
> True, using accessors will impair performance relative to calling the
> global directly.  But in practical terms you're only looking at a fraction
> of a *micro*second, so if you need to liberate your code base from direct
> storage references chances are no one will ever notice the performance
> difference.
>
> --
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>  LiveCode Journal blog: http://LiveCodejournal.com/**blog.irv<http://LiveCodejournal.com/blog.irv>
>
>
> ______________________________**_________________
> 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<http://lists.runrev.com/mailman/listinfo/use-livecode>
>
>