defining and using globals in an application

[Nonsanity]

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.

(I never did like having those single lines of code (aka "global TestVar")
living outside of any handler in my scripts. They were - if I may use the
past tense - an ugly feature of the language too...)

 ~ Chris Innanen
 ~ Nonsanity



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

> Francis Nugent Dixon wrote:
>
>  I think Scott has the right attitude. Use globals
>> if you need them, Use custom properties if you don't
>> like the power/scope/limitations of globals.
>>
>
> I would respectfully amend that to read:
>
> Use globals if you need them, use custom properties if you need data bound
> persistently to an object, and use accessors for anything else.
>
> Variables are volatile (they go away when the session ends), and that's a
> very useful feature in many cases.  Binding data to objects can cause those
> values to remain with the object if the object is in a stack that gets
> saved.  If you need values to persist between sessions then properties may
> be the best choice, but if you need volatility globals or accessors that use
> globals can be a better fit.
>
> --
>  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>
>