I think this statement by Ned is key to his feelings on the topic. I
think the problem has arisen because of potential misuse or
misunderstandings of the terms "namespace" and "scope" by various posters.
Note: The term namespace is a naming convention -- it has nothing to do
with scope. (Whenever I have written about this, I think I have
consistently used the term "namespace" and not "scope".)
In short, I agree completely with Ned.
I agree that there should be a naming convention to create "namespaces" for
variables that relate to an extension. I would personally prefer "::", as I
think it will look nicest with the existing syntax, and you rarely want to
use "::" in a string, but commonly want to use "." for something else, so I
think "::" is more specific.
Now, I would also like it agreed upon that all sieve extensions that
create variables SHOULD use a namespace using this naming convention. I
would even recommend that a sieve extension named "example" SHOULD use
"example." as the prefix on all of its variables. (I consider this a
Best Practice issue.)
The sieve extension name does sound like a good idea, but I would want us to
have date::year rather than variables::year, so there may be cases when one
extension defines several namespaces, and I think it might be too
restrictive and end up confusing to demand that all variables from one
extension have to go by the extension name.
With regards to "scope" are we definately sure that we want:
All variables have global scope: they are visible until processing
stops. Variable names are case insensitive.
Do we want to support any kind of local/file/global scope at all? It seems
that it's fairly universally agreed that global variables are pretty evil
(Lawrence has already made this point), so are we sure that we want to have
all variables global by default? (At the moment) I think would be in favour
of a :local :file or :global argument to the set command to indicate whether
or not this variable can/should "bleed" out of this script and into the
parent. I'd recommend that :file be the default rather than :global.
I note that Ned said:
I strongly object to this proposal
[http://www.imc.org/ietf-mta-filters/mail-archive/msg01211.html].
It adds considerable implementation complexity yet achieves negligable
benefits.
Variables give scripts capabilities they didn't have before and which
cannot be
achieved with any existing mechanisms. The same cannot be said for local
variables. I fail to see the capability they provide for real world
scripts
that cannot be achieved any other way.
Could I suggest that we say that "All variables have file scope: they are
visible only within the same .siv file, not spanning include boundaries".
Then later we support a "scope" extension that permitted :local and :global?
I think the argument for scope is to prevent users from making accidental
mistakes (rather than adding additional capabilities). I'm wondering if a
user would "expect" a variable in one script to be available to him in the
calling script, or in a called script. I would imagine the author would
expect variables to be local to the file by default, but would appreciate a
mechanism to explicitly ask that a file "bleed" into or out of an included
file etc.
Cheers
Nigel