defining and using globals in an application

[Richard Gaskin]

Nonsanity wrote:

> I actually prefer to use custom properties even for values that I want to be
> session-specific. The reason being that I'd rather have personal control
> over when the value is cleared than leave it to the environment to handle.
> This way I can be sure I know the contents of the variable (as a custom
> property) at all times. It never gets changed out from under me, and so will
> never surprise me or my code.
>
> With globals, you need to handle the case of an empty (unset) value
> everywhere the global is used, or you need to initialize the global to a
> starting value at startup - The place where it will get emptied at the start
> of each session.
>
> Using a custom property, if you need the value to be reset to a particular
> value on startup you do it yourself in the OpenCard or PreOpenCard. If you
> want it to be emptied like a global, you can do that there too. But at least
> you have all the control yourself. No more surprises.
>
> I really only use globals when I'm doing a quick hack script for debugging
> purposes, but even there my old Hypercard habits (where globals were the
> only option) are being replaced with custom properties.
>
> I really do think of custom properties as the complete replacement, in all
> ways, for globals.

Respectfully, those issues and solutions seem to work both ways.  For 
example, you can set the value of a global on preOpenCard just as easily 
as you can set the value of a property, and any script from anywhere can 
alter a property just as easily as it can alter a global.

For myself, in addition to the persistence issue (I'm a compulsive 
saver) it comes down to simply laziness - I'd rather write:

   SetDefaultWidgetHeight 200

...than:

   set the uDefaultWidgetHeight of button "someButton" \
     of card "someCard" of stack "someStack" to 200

Where properties are unbeatable is when you need to bind data to a 
specific object. If you have multiple objects in which each need a 
different value, implementing those as properties is the with-the-grain 
solution.

But if you need something that's global in scope, I see no harm in using 
globals.

 From time to time I come across recommendations that globals are 
somehow bad practice, yet almost every language supports them so I'm 
inclined to think they have a place among our options for value storage.

--
  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