What's wrong with Globals?

[Jim Ault]

On 3/30/07 4:41 PM, "Joe Lewis Wilkins" <pepetoo at Cox.Net> wrote:

> 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 
Do this very quick exerciser and you will see an array, and then it will put
them into custom properties.

make a new mainstack
paste into the stack script

---- copy from here ----------
get the properties of this card --an array
combine it using cr and tab --converted to a list
put it into message box  --now we can see it

get the properties of this card --an array
set the custom properties of this CARD to it
--now stored in the card
--the key = the name of the property
--the element = the value ("true", 0, blue)

set the custom properties of this STACK to it
--now stored in the card

---- end copy -----------
--now use the inspector palette to view the custom properties

and then you could

set the customproperties of this STACK to empty -- all gone


Jim Ault
Las Vegas


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