On Mon, 2006-06-26 at 19:37 -0400, Mark E. Mallett wrote:
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)?
one option here is to get rid of export, and instead do it as an option
to the "include" action.
include :export ["foo", "bar"] "myscript";
(the specified variable names should be constant strings, ie. without
variable expansions, to reduce the number of exploding head incidents.)
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.)
do you get any control over access then?
it's probably better to think of import/export as the parameter list
supplied to the sub-script, rather than as a scoping thing. a variable
which is exported, will only be available to the directly included
script. in fact, the sub-script is prohibited from re-exporting the
variable to its sub-sub-scripts, it has to make a copy with a different
name if it needs to do such a thing (aside, I don't think we need that
restriction, I can't see what we gain from it).
so when you call (actually include) a procedure (actually sub-script),
your exported variables are the named parameters for that procedure, and
the procedure may return values to the caller by modifying these
exported variables.
switching to an :export keyword may make this more intuitive.
--
Kjetil T.