i.e. take the following script.
require "regex"
if (header :regex "Cc"
"Some regular expression or other") {
fileinto "FolderName";
}
If we support both fileinto and regex are we meant to produce an error
here?
<snip>
Could someone clear this up for me? I'd suggest a re-wording of the section
to make the intention clearer/more spelt out.
I have to say I see nothing unclear here. If you don't have a require clause
for a particular extension it isn't legal to use it. Requiring an unrelated
extension doesn't change this.
Well I seem to have interpreted it correctly, so from that point of view I
guess it is clear, but I just don't understand why we want to operate this way.
Why should it only be legal to use an extension if it was previously declared
with a require command? What does this gain us? I agree that it is naughty to
use a command without "require"-ing it beforehand. GUIs/users should make
every effort to make sure this list is upto date. But it seems a bit harsh to
fail a script when it uses an extension that we know about, where it wasn't
"require"d at the top of the script.
It certainly makes things more complicated in our Sieve engines as we need to
have a list of available extensions that is added to by means of the require
command. Then whenever we find an extension we have to check its presence in
our list.
Do we want the require command to "enable" extensions because a script should
really be thought of as a whole, and if we can't do part of it then we
shouldn't do any of it? If this is the case then surely a just-in-time parser
is a really bad idea, as it will pass some scripts that a
full-parse-then-execute implementation will fail.
Do we want the require command to "enable" extensions because future extensions
may have much further reaching structural consequences so if we don't
understand the extension the can't guarantee that we can use any of the script
correctly? Again this is yet another reason why just-in-time parser are really
going to be a rubbish solution.
But then a just-in-time parser solution is a great idea, dramatically saving on
execution time on a busy server.
Is it because we want to force scripts to have upto date require lists?
I don't see how we can say that the require command "enables" the use of the
extension for the current script, and that therefore the use on an extension
without corresponding require command is an error, but then also say that it's
alright to have a just-in-time implementation. On a related point about
section 2.10.6 I'd say that implementations SHOULD "go so far as to ensure that
execution is atomic (either all actions are executed or none are executed).",
not "might even".
I probably just need to hear the arguments. If someone could explain then that
would be great. Something more than just an "IMO" please.
Cheers.
Nigel