lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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);
     module_table[module] = newmodule

Reload could be defined as:

  function reload(module)
     module_table = getmoduleTable();
     fixmodule = module_table[module]
     old_global_table = setGlobalTable(fixmodule);

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

David Jeske (N9LCA) + +