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.
Well, I wasn't a strong proponent of this scheme, so I'm probably not the one
to explain it. Nevertheless, it is my understanding that there was a strong
desire to be able to determine authoritatively the extensions a given script
uses based on a cursory examination of the initial part of the script.
One of the reasons why this is useful is because in general it may not be
possible to determine exactly what extensions a given script uses. For one
thing, the names of the commands or paramters or whatever involved in an
extension may not correlate with the extension name. And in fact it is
possible that dependence on an extension isn't even derivable from an
inspection of the script content.
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.
Well, once there's a consensus that such a list should be part of all scripts,
it is obvious that the only way to insure the presence of such a list in every
script is to make things fail when it isn't present. We have way too much
experience with optional declarative mechanisms to believe otherwise. And a
declarative scheme like this that is used only occasionally is worthless.
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.
You're looking at it backwards. The use of require makes it possible to use
just-in-time schemes. Without it things get messy -- you have scripts that
succeed sometimes and fail other times, and that violates the least
astonishment principle big time.
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.
Again, you're looking at it backwards.
But then a just-in-time parser solution is a great idea, dramatically saving
on execution time on a busy server.
Sure.
Is it because we want to force scripts to have upto date require lists?
We want this too.
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".
Given that in many implementations some actions may be deferred or even
passed off to an entirely different agent to implement, I don't think this
is practical.
Ned