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

["Aaron Stone" <[e-mail]>]

On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:

> On Thu, 2005-08-25 at 15:30 +0000, Aaron Stone wrote:
>> On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:
>> > "All variables have global scope: they are visible until processing
>> > stops."
>> > 
>> > 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.

[snip]
> 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.

Aaron