On Mon, Jun 26, 2006 at 08:36:50PM +0100, Nigel Swinson wrote:
In:
The "import" command contains a string list argument that defines one
or more variables names of variables exported and set by other
[aside: too many "variables" there]
scripts which should be made available to the current script.
and:
If an "import" command lists a variable that has not been exported
and set by any other script at that point during the SIEVE execution
process, then an error MUST occur.
If you remove "and set" as agreed, then what is the difference between
import and export? I'm not clear why we can't just have a "global"
command with a string list argument of variables instead. Either that
or just specify that all variable names starting with "global." have
global scope.
In preparing some comments (so far left on the floor), I had come up
with some twisted examples to illustrate questions about how import and
export interact, specifically contrasted with simple global variables.
The best I can make out is that import and export coordinate through
some sort of import/export namespace (as contrasted with global
namespace, which it really isn't):
- import pre-initializes a variable's value from the same-named
variable in the import/export namespace, requiring that at some
other point in script execution, some code has set up that variable
in the import/export namespace;
and
- export says that whenever a script context changes (i.e. it
'return's to its includer, or it 'include's another script), the
exported variable's value is published into that of the same-named
variable in the import/export pool.
If this is correct, then it just makes me wonder: wouldn't it be just
as useful to make "import" and "export" be action commands, allowing a
script to push and pull variables out of the import/export namespace
without being subject to unintended side-effects (i.e. of not being able
to predict what, exactly, included scripts export into your nicely
imported variables)? And that in turn makes me wonder, why not just use
a reserved namespace (like "include.") and use "set" to do those
manipulations? (Which is similar to what you said re 'global' only more
in line with what I read into what import/export is trying to do.)
Must we say this?
The "import" command, if present, MUST be used immediately after any
"require" commands (at least one of which will be present listing the
"include" extension). Multiple "import" commands are allowed. An
error occurs if an "import" command appears after a command other
than "require" or "import". Use of the "import" command makes the
listed variables immediately available for use in the body of the
script that uses it.
I would imagine a use of import would be linked to some kind of
"rule". If later we remove the rule, we may forget to remove the
variable names from the "import" and then our "import" command will
slowly fill up with silt. I'd prefer to "declare" the variables near
their use. Is there some technical reason why we want it that way or
are you trying to enforce a script writing prefence?
This restriction in C is one of the reasons I tend to convert .c files
to .cpp even if I have no immediate plan to use objects. :o(
Yes, I think there's too much magic in import/export as currently
described. In fact I'd prefer a whole nother approach to what 'include'
is trying to accomplish anyway, but that's for another potentially
inflammatory post :)
mm