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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
