Stack Level Local/Globals

Dennis Brown see3d at writeme.com
Wed Jul 6 12:15:59 EDT 2005


On Jul 6, 2005, at 9:22 AM, Robert Brenstein wrote:

> ... any stack-based definition of scope is restrictive one way or  
> the other. If we make it only a single stack, it is very limited.  
> If substacks are included, then it is less but it still lacks  
> flexibility. What if I do not want the mainstack to have access to  
> some global but have a few substacks share them? Or just have a  
> global specific to a single substack? What if my project  
> encompasses a couple mainstacks (including a standalone with  
> substacks kept independently, not so uncommon situation -- granted  
> I could use then normal globals but that restricts development in  
> IDE)? What about situations when a program clones its substacks,  
> like IDE editor?

Robert,

The idea behind all the various global/local declarations, is that  
they start at a certain point in the stack script hierarchy and work  
down from there.

A global is accessible everywhere, even places that are not likely  
intended.  The problem is that you might choose a name that somebody  
else also used, or that you might have used in another project that  
you load into the IDE at the same time as your current project.  This  
possibility puts significant constraints on what names you can safely  
use for globals --which goes against the idea of making a name  
descriptive of its use.  Everyone seems to agree that we need a  
solution for this.

A stack scope variable would be accessible to a main-stack and its  
sub-stacks only.

I proposed that a stack scope variable would be the effective  
replacement for globals in most projects, isolating them from the IDE  
and other project stacks.  That way the user is in charge of his own  
mistakes.  I believe this is a useful concept in its simplicity.  It  
is very much in keeping with the current scheme and would cover most  
situations for the beginner who is the most likely to get tripped up  
by globals.

As far as restricting the scope in your own projects. If you are  
writing your own projects, then you are in charge of the naming of  
variables for your project.  You can easily choose names and declare  
them only in the places you want to use them.

However, you are right that they do not carry the same expanse of  
scope as a global.


> The concept of namespaces is inherently more flexible and allows  
> more control in any direction and scope without binding to a  
> specific object and without imposing any preconditions. So, what  
> you suggest would just be one possible scenerio. Namespaces would  
> allow libraries to have documented globals. It would allow to use  
> globals instead of remotely accessing custom properties.
>
> I also think that having namespaces will be a prerequisite for  
> making Rev more OO, which is on the planning board.
>
> Robert

My proposal does not mean that I am not in favor of an additional  
namespace scheme.  This might be favored by professional programmers  
and IDE tool makers.  I have also proposed in another thread the  
possibility of declaring a name that can be invisibly appended to  
global names internally that would in fact make your globals unique  
without having to deal with the ugliness of the name everywhere in  
the scripts.  Kind of like setting the itemDel.  I also proposed  
other schemes.

Please describe for us unfamiliar with namespaces how you would  
envision them working and the syntax with Transcript.

Thanks,
Dennis



More information about the use-livecode mailing list