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

[Kjetil Torgrim Homme <[e-mail]>]

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?

> > [:global] would be a no-op, but a :local modifier is definitely possible if
> > needed.
> 
> It would only be a no-op if the default namespace is the global namespace
> ;-) Unless you guys are already deeply along the path of a single
> namespace, I believe a per-file namespace is less likely to cause
> confusing results.

I personally find a global namespace to be the less confusing option.
cutting the script into pieces and including those from a master file
shouldn't change its meaning, IMHO.  (you'll usually need to duplicate
require statements, though.)

> A :local modifier would do the trick. The text in the drafts should be
> more explicit about there being a single global namespace for all scripts.

there is only one script, it just so happens that it may consist of more
than one 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.
-- 
Kjetil T.