On Thu, Feb 21, 2002 at 03:46:10PM -0600, Roberto Ierusalimschy wrote:
> The second is that there is no easy and simple way to avoid using
> the dot notation for every reference to an "imported" object. Then I
> presented an idea we have been discussing before (the "mechanism that
> forces variable declarations").
>
> The mechanism is as follows: first, we start with the "obvious" global
> declarations:
>
> global a,b,c
>
> But then we add an optional item to the declaration, that states in what
> table those "globals" live (yes, it is strange, "global" does not declare
> globals anymore... but let us forget that for now). So, if you put functions
> 'b' and 'c' in a module "m", you can access them directly after the
> following declaration:
>
> global (m) b, c
Why require the declaration of where the globals live?
How about changing the machinery to bing the current "global table"
for a function to a local variable of the function at definition time?
The equivilant of writing:
function myfunc(a,b,c)
local _g = %GLOBALS; -- all globals accessed
print(_g.test); -- printing a global variable
end
If this were made implicit, then dofile() would still operate as it
does today, but module builders could easily write require as:
function require(module)
module_table = getmoduleTable();
newmodule = {}
old_global_table = setGlobalTable(newmodule);
dofile(module)
setGlobalTable(old_global_table);
module_table[module] = newmodule
end
Reload could be defined as:
function reload(module)
module_table = getmoduleTable();
fixmodule = module_table[module]
old_global_table = setGlobalTable(fixmodule);
dofile(module)
setGlobalTable(old_global_table);
end
Finally, if that globals table were actually an extra paramater,
things could get interesting for objects. For example, if the code
underneath worked like this:
function myfunc(a,b,c,_g = %GLOBALS)
print(_g.test) -- print global variable
end
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net