[Top] [All Lists]

Re: I-D ACTION:draft-daboo-sieve-include-03.txt (fwd)

2005-08-25 16:58:48

On Thu, Aug 25, 2005, Kjetil Torgrim Homme 
<kjetilho(_at_)ifi(_dot_)uio(_dot_)no> said:

On Thu, 2005-08-25 at 15:30 +0000, Aaron Stone wrote:
On Thu, Aug 25, 2005, Kjetil Torgrim Homme 
<kjetilho(_at_)ifi(_dot_)uio(_dot_)no> said:
"All variables have global scope: they are visible until processing

I find this sufficiently clear to answer "yes" to all three of Cyrus'
questions, but then I wrote it :-)

I wouldn't have gotten that on my own in a million years, neither in
implementing a Sieve interpreter nor in writing my own scripts. 

okay, would you interpret that statement differently, or is it just
easily overlooked?

Both... it's only a single sentence, and a major issue. I think a section
entitled "Scope" at around 4.2 or 4.1.4 would be best. Also, when the
issue comes up the user or implementor will have the question, "Why does
my variable contain weird values after an include?" or "Why can't I access
a variable set in another file?" and the answer should be explicit to
those questions.

there is only one script, it just so happens that it may consist of more
than one file :-)

Ok, but that doesn't change my position ;-)

:local would be like C's static applied to a variable in the file.

The very presence of a :global and/or :local modifier makes for an
explanation that will clarify things for implementors and end users alike.
On this point, what do folks think?

I don't think it is a very important point.  the scripts I see tend to
use a "stop" as soon as possible, and there is little need to keep state
across an include statement.  the risk of having your state trampled on
is small, especially since you'll tend to control all the script
components yourself.  indeed, I think it would be more common to use a
global variable set in the included file to return the result to the
calling file.

Include will allow more sites to create libraries of common scripts. These
scripts will want to keep most of their namespace clean and/or protected.
Prefixed on the variables might work, but a :local / :global mechanism
would make these protections more explicit.