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 <ambassa...@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@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> > > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
