What's wrong with Globals?

Tue Apr 3 04:14:24 EDT 2007

Si, the syntax is <start using stack "someStack">,  which puts  the  
script of stack "someStack"  into the message path ie. available to  
all other open stacks.

The script of a mainstack of an app is already in the message path,  
so you wouldn't need to put a mainstack 'in use'.

<Start using> is probably the most common way that library stacks  
(stacks containing lots of re-usable handlers) are implemented. Many  
of us have built up collections of generally useful handlers which we  
put in a library stack, and put 'in use' (both in compiled apps, and  
in the IDE) so we don't have to re-write them for every project.

For instance, quite a few people coming to Rev from other languages  
ask here about a 'trim' function (to trim white space from the  
beginning and end of a string), which is not a built in function, but  
is very commonly wanted, so many of us will have written one like:

function trim pString
   return word 1 to -1 of pString
end trim

and rather than having to write this function for every project, you  
can put it in the script of a library stack containing many such  
useful functions, and copy that stack into each project you start,  
and put it 'in use' at startup.

It also makes it possible for people to write libraries of handlers  
that they can then share with or sell to others. RevOnline contains  
many libraries that people have decided to share, and so there is a  
great deal of extra functionality available to us that is not part of  
the regular Rev install.

Best,

Mark

On 3 Apr 2007, at 09:49, Simon HARPER wrote:

> So as a newbie, would I be right in thinking that you can call any  
> function from the library stack in any other stack, or must the  
> library stack be the mainstack. Also you say "put 'in use' at  
> startup" do you have to do this via a specific command?
>
>
> Cheers
> Si.
>
> ====
> Simon Harper
> 2.44 Kilburn Building
> University of Manchester (UK)
>
> Pri: simon.harper at manchester.ac.uk
> Alt: sharper at cs.man.ac.uk
>
>
> On 2 Apr 2007, at 23:20, Mark Smith wrote:
>
>> Well, I'm certainly not going to presume to criticise your method,  
>> but in the spirit of "you show me yours, I'll show you mine", what  
>> I tend to do is to have a stack in my apps which is put 'in use'  
>> at startup, and which has various getters and setters. The actual  
>> data it returns could be in cps, script locals, text files,  
>> databases or somewhere on t'internet, the calling handlers don't  
>> have to know. So:
>>
>> answer gcOK() in a handler calls the gcOK() function in my library  
>> stack which might be
>>
>> function gcOK
>>   return "OK?" -- literal
>> end gcOK
>>
>> or
>>
>> function cgOK
>>   return the okMessage of me -- cp
>> end gcOK
>>
>> or
>>
>> function gcOK
>>   return sOkMessage -- script local
>> end gcOK
>>
>> or
>>
>> function gcOK
>>   get URL (http://www.google.com/search?q=OK"
>>   --parse html and find what you need
>>   return whatYouFound
>> end gcOK
>>
>> etc.
>>
>> This approach proved very handy indeed recently, when the data  
>> (retrieved from the web) for one of my apps changed format, but  
>> all I had to do was re-write a couple of getter functions, the job  
>> was done, and I felt quite smug.
>>
>> Script locals are quite a neat way of achieving data-hiding when  
>> used this way.
>>
>> Best,
>>
>> Mark
>>
>>
>>
>> On 2 Apr 2007, at 23:53, Graham Samuel wrote:
>>
>>> Forgive me if this conversation has ended, but my internet  
>>> connection has been in meltdown... just got back on line.
>>>
>>> I most frequently use globals because there aren't global  
>>> constants. I use them very largely for strings containing stuff  
>>> like error messages or even very simple strings like "OK", so  
>>> that I can refer to these indirectly in scripts, thus allowing me  
>>> to switch (human) languages by redefining the globals in just one  
>>> script of the program. I guess I could have used custom property  
>>> sets with exactly the same effect, and with the advantage that I  
>>> wouldn't have to initialise them during the startup of my app,  
>>> but like many others I didn't understand these when I started,  
>>> and I tend to re-use stuff I wrote before. I guess there isn't  
>>> much difference between writing
>>>
>>>   answer gcOK  -- 'gcOK' is a global with a string in it.
>>>
>>>        and
>>>
>>>   answer (the gcOK of stack "allTheConstantStrings") -- 'the  
>>> gcOK' is a property of some object.
>>>
>>> but the second statement seems to have more characters in it,  
>>> since it involves referring to the object in which the property  
>>> is stored. If there are a lot of such references, my scripts are  
>>> going to get longer.
>>>
>>> I also use globals when I have a quantity which needs to be used  
>>> in different scripts in different stacks, i.e globally: a very  
>>> obvious point, but I really don't see what is wrong with that. I  
>>> do accept that I have to be disciplined about changing their  
>>> values. I do use properties (I tend to use these for global  
>>> status stuff like 'the soundOn of this stack'), parameter-passing  
>>> and message-passing extensively, but to me globals feel right for  
>>> quite a lot of things.
>>>
>>> I shall now wait for someone to tell me why this is a really  
>>> wrong-headed approach. I'm always willing to learn - really.
>>>
>>> Graham
>>>
>>>
>>> ----------------------------------------
>>> Graham Samuel / The Living Fossil Co. / UK and France
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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