What's wrong with Globals?

[Joe Lewis Wilkins]

Thanks, Jim. I knew you'd come through. So really what we have with  
CPs is some potentially elaborate arrays of somewhat simplistic form.  
You said tables, to me that means matrices - Columns, rows,  
essentially spreadsheet arrangements of data that in other languages  
would use dot syntax for access. The other stuff I understand after  
years of exposure to it, so maybe I'll get used to CPs and Groups...  
Someday!

Thanks,

Joe Wilkins

On Mar 30, 2007, at 4:10 PM, Jim Ault wrote:

> On 3/30/07 3:18 PM, "Joe Lewis Wilkins" <pepetoo at Cox.Net> wrote:
>
>> Please enlighten me. With HC I never really had any problem using
>> Globals pretty extensively. I know all of the "old" adverse thoughts
>> and how it was felt to be bad programming practice; and, perhaps,
>> before we could have some pretty long vars, maybe it was tough coming
>> up with names that didn't create conflicts, but I think we're past
>> all of that now. So... why is using Custom Properties any better than
>> using globals. I need to be convinces. I suspect a few of you have
>> first hand experience and I'd like to hear them.
>
> Nothing wrong with them, just some downsides for data management in  
> larger
> projects.  Declaring a global makes it exist, therefore you cannot  
> easily
> test to see if it has been used before the moment you declare it.   
> Testing
> for empty does not mean that another handler did not create it.
>
> Basically, globals are all owned by Rev, which means you can close  
> a stack
> and remove it from memory, but not the globals.  You need to delete  
> the
> global or quit and relaunch Rev.
>
> Globals can be modified by any handler in any stack, even the Rev
> environment (all that stuff behind the scenes).
>
> Globals are not saved with the stack, custom properies can be, but  
> this may
> not be an issue in most cases.
>
> My biggest benefit is that globals fill the variable watcher and make
> debugging a lot more challenging.  When I name my globals, I prefix  
> with "z"
> so that they appear at the bottom of VW, and the script locals with  
> "x" so
> they appear just above the globals.  Just my little quirk.
>
> You can use the same custom property name to store different  
> information
> such as
>
> ---using a global ---
> get the short date
> put it into line (the number of this card) of gLastVisitToThisCard
> --of course, now where to store this for next time
>
> --using custom properties
> get the short date
> set the cpLastVisit of this card to it
> save this stack
> --now each card has its own data
> set the cpLastVisit of this stack to it
> --now the stack holds the last date any card was visited
> set the cpCdIdVisited of this stack to the short id of this card
> --now the id is stored
>
> ---In a substack
> put the cpCdIdVisited of stack main stack into cdIdToUse
>
> thus globals are general locations, custom properties are specific
> locations.
>
> Further, if you open a stack from somewhere to check out the tutorial,
> example, etc,  those global declarations stay with Rev and  
> overwrite any
> previous values.
>
> Part of the idea is that now your data has a specific place to be  
> attached
> that disappears with the stack or substack when removed from  
> memory, yet is
> still accessible, even if the stack is not open.
>
> Script locals are a better management technique in my opinion.
>
> Let us not even get into the power of custom property sets and storing
> arrays in this thread.  Very powerful stuff.  A custom property set  
> is the
> same as an array... it has a name, keys, and elements.  You can  
> have as many
> as you like.
>
> Jim Ault
> Las Vegas
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution