What's wrong with Globals?

[Jim Ault]

Hey, good job, Richard, this is may actually get to be a useful thread!

I did not say I did not use globals, but that they become difficult to
manage in complex projects.  I am going to be rewriting a major set of
stacks this summer, and will drasticly cut down the number of globals.  My
biggest difficulty is tweaking the code and debugging the work I did 2 years
ago.

Variable watcher has become a challenge because I have loaded it with so
many globals starting with 'g' that don't have anything to do with the
handler I am tracing.  By switching to 'z', at least the globals fall to the
bottom.

[aside: globals are what I reach for when I am not sure where I am going
with my design.  If this process goes on long enough, it becomes very messy.
I then can see how I should have designed my data storage and access, but
what a job to fix it :-)]

In this particular project, custom property sets make more sense for me.
Think of stock market data throughout the day.  Most of the data points
become obsolete within minutes, but are critical to updating a user
interface and making decisions.  Several data points need to be benchmarked
and stored.  Now lets say you create "a group of globals" to track info
about the same stock symbol, and we are following 15 stock symbols today,
thus each global times 15.   This is a natural for custom property sets, and
tricky for globals and handlers to maintain them.

set the custompropetyset of this stack to "cpsNASDAQ"
--now any handler working with data (such as open, close, bid, ask, etc)
will update the NASDAQ 'table' or property set.
set the custompropetyset of this stack to "cpsSP500" --another table INSTEAD
--this is like using another set of globals with the same gNames.

Here you would not have to change global names, or use indirect references,
yet the stored data would be available in any stack in Rev.

--from anywhere
put the cpsSP500[cpBid ] of stack "TradeLots" into currBid
put the cpsNASDAQ[cpBid ] of stack "TradeLots" into currBid
put the cpsNASDAQ[cpAsk ] of stack "TradeLots" into currAsk
set the cpsNASDAQ[cpSpread] to (currAsk - currBid)

set the cpsSP500[cpMktTime] of stack "TradeLots" to the short time
set the cpsNASDAQ[cpMktTime] of stack "TradeLots" to the short time
--or this way ---
set the cps of stack " TradeLots" to " cpsNASDAQ"
set the cpMktTime of stack "TradeLots" to the short time

put askWifesParentsForMoreMoney into future
get (the cpsSP500[cpCurrProfit] + the cpsNASDAQ[cpCurrProfit])
put askWifesParentsForMoreMoney into immediateFuture

So now you have instant access to tables of data (NASDAQ, SP500) using the
same variable names/(or different if you wish)/ (cpBid, cpAsk, cpMktTime)
from any handler, at any time without declaring local or global variables or
worrying about scope.  Add two new subStacks and no need to declare globals.

To start the day...
on openstack
   set the custompropetysets of this stack to empty
   --or more likely
   set the custompropetyset "NASDAQ" of this stack to empty
   set the custompropetyset "SP500" of this stack to empty

   GET the custompropetyset "CurrPostion" of this stack
   combine it using cr and tab
   put it into fld showCurrPosition
   --3 step reporting of a property set ---
   --more elaborate reporting -----
   replace comma with tab in it
   put it into fld showCurrPostion
   set the clipboarddata to it
   --now paste it into an Excel spreadsheet ---
end openstack
-------------------------------------
Question:  Are you already using a custom property name?
put the customKeys of this stack into message box
--or--
get ("cpPetName" is among the lines of the customKeys of this stack)
answer it
-------------------------------------
Keep an hourly record of the stats as blocks of 'global variables'
set the customproperties["cpsNASDAQ0900"] of this stack to \
     the customproperties["cpsNASDAQ"] of this stack
save this stack
set the customproperties["cpsNASDAQ1000"] of this stack to \
     the customproperties["cpsNASDAQ"] of this stack
set the customproperties["cpsNASDAQ1100"] of this stack to \
     the customproperties["cpsNASDAQ"] of this stack
-------------------------
put the customproperties["cpsNASDAQ"] of this stack into dataArray
--all variables are now in dataArray
------------------------
--remote possiblities
set the customproperties of this card to dataArray
go card 6 of stack "Report Stack"
put the customproperties of recent card into dataArrIsNowHere
set the customproperties of recent card to empty
--or --
set the customproperties of card 6 of stack " Report Stack" to dataArray
go card 6 of stack " Report Stack"
--or--
set the custompropertysets of card 6 of stack " Report Stack" to \
     ("cps"& the short date)  --use the date as the set name
set the customproperties of card 6 of stack " Report Stack" to dataArray
go card 6 of stack " Report Stack"
--use the current property set with "of this card"
-------------------------------------
--update the property set from any handler any where
set the custompropertysets of card 6 of stack " Report Stack" to \
      ("cps"& the short date)
set the cpHighBid of card 6 of stack "reportStack" to currHighBid
set the cpHighAsk of card 6 of stack "reportStack" to currHighAsk
get the the customproperties of card 6 of stack " Report Stack"
combine it using cr and tab
put it into fld "dailyStats" of card 6 of stack " Report Stack"
put it into message box
------------------------------------

To do the above would take lots and lots of globals. repeat loops, list
managers,  and probably (word,item,line) chunks + itemoffset, lineoffset.
--------------------------------------
Question:   Has any value in the table (cp set) changed?
set the customproperties of this CARD to the customproperties of this STACK
--then later
put the customproperties of this stack into currVer
put the customproperties of this card into prevVer
combine currVer using cr and tab --now a list
combine prevVer using cr and tab --now a list
if currVer <> prevVer then
 -- then something was changed at least once by some handler somewhere.
----------------
--you can categorize you data storage in logical tables
set the propertyset of this stack to "cpsStatusVars"
set the propertyset of this stack to "cpsTimerVars"
set the propertyset of this stack to "cpsEventVars"
--which can be updated from anywhere, checked and reported.
-------------------

If a lot of data is to be manipulated and complex reports/queries done, you
should be thinking about a real database like SQL or Valentina or other.

I think that an article tied to live examples would be a very good article.
I will help.

Jim Ault
Las Vegas


On 3/30/07 10:50 PM, "Richard Gaskin" <ambassador at fourthworld.com> wrote:

> Mark Wieder wrote:
> 
>> Globals are what I usually think of as the way people start out using
>> variables until they learn better ways.
> 
> This raises the central question:
> 
>    If using globals are to be seen as a Very Bad Thing,
>    why is it that some of the world's most experienced programmers
>    keep designing languages that support them?
> 
> :)
> 
> Nearly any attribute of any entity can have both good and bad effects.
> I believe the same is true for global variables.   While I agree with
> every point you made, most of them also apply to custom props and some
> can even be helpful features of globals.
> 
> I tend to agree that HyperTalkers are especially prone to using globals
> in places where alternatives may do more for them.  But in HyperCard
> that's all they had, there were no custom properties or script-local
> variables.  Who could blame the Bedouin for not knowing how to swim?
> 
> But on balance, I believe there's a good reason most languages have
> globals in their design.  When you need 'em, you need 'em.
> 
> The tough part is knowing when you need 'em.
> 
> 
> Maybe some brave soul with time on their hands can fill in this matrix:
> 
> 
>                       Best For...       Not So Good For...
>                      -------------     --------------------
>            Globals
> 
>             Locals
> 
>      Script-Locals
> 
> Custom Properties
> 
> 
> 
> If anyone wants to take a stab at something like that I'll gladly post
> it at revJournal....