Hi Nigel,
--On August 26, 2005 2:44:29 PM +0100 Nigel Swinson
<Nigel(_dot_)Swinson(_at_)rockliffe(_dot_)com> wrote:
I don't think we need ":global", and it would be confusing to use.
I consider PHP a very mature scripting language and I consider thier
scoping rules very well thought out most likely very carefully discussed.
After using the language for several years I haven't really found fault
with them. It make me think it's worth copying what they have done. And
thus:
I think Aaron and I are suggesting:
Set file scope variable
set "var" "Hello Kitty";
Set global scope variable, where global affects all scripts that come
into existance with the include spec set :global "var" "Hello Kitty";
Set local scope variable, where local affects the current and nested
command block (filescope if not currently in a control block.) (would
doubt would ever be used) set :local "var" "Hello Kitty";
And Kjetil seems to disagree. Anybody else out there have any opinions?
I do think the security concerns that Nigel brought up are valid. As such
there does need to be a way for script authors to prevent their variables
from being used either in an included script or by the scripts that include
it. A simple solution to that would be a ":private" and ":public" scoping
where ":private" means file scope only. The default is ":public" scope.
One thing with scoping that we also have to be concerned with is handling
errors. What if a script attempts to use a ":private" variable from another
script? Should that be a run-time or activation time error? Or should sieve
do something sensible, e.g. make the new variable ":private" too? It would
probably be better to have errors at activation time. In fact I would also
suggest having warnings at activation time to warn of variables from one
file being used in another, if the user wants to know about it.
--
Cyrus Daboo