global problems> benefits

[Jim Ault]

Hypertalk, as I understood it from the beginning, was to be a free-form
style of programming that allowed interacting with many stacks, even
hundreds on multiple drives and computers.  One major concept was the
navigation to prev>next>recent>push card>pop card.  All this could involve
'jumping' to a new stack each step and the stack did not even have to be
open in memory before the leap, and could be closed after use.

Think about jumping directly to a card in a stack that is not even open yet,
then back 10 steps with one click.  The only stack that had to remain open
was Home.

This structure required Hypercard, the application, to hold many values and
user preferences, mostly in the Home stack and resource fork.  Also in the
concepts were 'stacksInUse' (which could be changed on the fly, using up to
10 at one time via startusing + stopusing) like a dynamic library of
functions.

Then the fabulous "re-writing a script" and then running it, on the fly
[>set the script of button "ShowUsersFace" to "on mouseUp, go card
"face112", end mouseUp", send mouseUp to button " ShowUsersFace"]

[>set the script of button "ShowUsersFace" to ""  ]  it now does nothing.

This edit on the fly could re-program the interface depending on conditions
and user choices.  I used it often in point-of-sale software.

Also 'the target' and 'me' and 'the clickline', etc are not compiler-style
objects but we have come to like them, love them, and hold them dear.

In the IDE, 
"global gUserName" 
is saying create a variable in the IDE space, not the stack space.  For a
compiled app, the global is maintained in the Mainstack space (ala Home).

Jim Ault
Las Vegas


On 8/2/05 1:39 PM, "Eric Chatonet" <eric.chatonet at sosmartsoftware.com>
wrote:

> Hi all,
> 
> I was very busy and did not follow accurately this thread.
> I don't speak English very well but I know what global means: global
> means global :-)
> If you can empty a global, delete it from memory when needed, where
> is the problem?
> You can use good scripting conventions to be sure that local and
> global can't shadow.
> 
> Above all, we have to remember that Rev is intended to build
> standalones.
> IDE behaviour is another thing and IDE is not the target.
> On the other hand, you have many other ways to organise data if
> globals don't suit your needs: local, script local, custom
> properties, external files, substacks and many others :-)
> I saw very clever examples where globals are essential by Chipp and
> Jacque.
> But if there is a better way to go, use it ;-)
> The question does not seem to be a "global" problem, but a question
> about the architecture you choose.
> Rev provides many ways to do the job: choose the best one!
> My two cents.
> 
> Best Regards from Paris,
> 
> Eric Chatonet.
> 
> Le 2 août 05 à 22:15, J. Landman Gay a écrit :
> 
>> Mark Wieder wrote:
>> 
>>> Jacque-
>>> Tuesday, August 2, 2005, 8:07:41 AM, you wrote:
>>> 
>>>> Globals are necessary when one has a suite of stacks that must
>>>> interact
>>>> as a unit. One very common example is a "find" handler. Assume a
>>>> number
>>>> of data stacks, each a clone of the others. A handler asks what
>>>> you want
>>>> to find and puts that string into a global. The next time the
>>>> user wants
>>>> to find something, you can use the same string to allow a persistent
>>>> search across many stacks.
>>>> 
>>> Yes, I do understand what globals are and why one may want to use
>>> them. I do actually use them, albeit sparingly. My conceptual problem
>>> here is with the persistence of global variables in the IDE once the
>>> stack or suite of stacks that used them has been purged from memory.
>>> In your example, can you think of a reason for the "find" string to
>>> persist after you have closed the suite of stacks that initialized
>>> and
>>> used the find handler and you've gone on to work on another project?
>>> 
>> 
>> Sure. How is Rev supposed to know I'm done with it? Suppose I close
>> one data stack and then open another one? I still want my global
>> available. I'd much rather be in charge of removing it myself.
> 
> ----------------------------------------------------------------
> So Smart Software
> 
> For institutions, companies and associations
> Built-to-order applications: management, multimedia, internet, etc.
> Windows, Mac OS and Linux... With the French touch
> 
> Free plugins and tutorials on my website
> ----------------------------------------------------------------
> Web site        http://www.sosmartsoftware.com/
> Email        eric.chatonet at sosmartsoftware.com/
> Phone        33 (0)1 43 31 77 62
> Mobile        33 (0)6 20 74 50 86
> ----------------------------------------------------------------
> 
> _______________________________________________
> 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