Re: Globals in 5.0 Alpha

[Edgar Toernig <froese@...>]

I wrote this shortly after the 5.0-alpha release but later
thought to wait a little bit to see how the new globals are
used.  But I think it's time now ;-)

John Belmonte wrote:
> 
> The Lua team did a good job of reducing the complexity of the original
> globals plan, and yet the result is still very powerful.

Powerful it may be, but with the complexity I dare to disagree ;-)
It's even more obscure than the previous global statement *g*
Let me explain:

  1) You no longer have one "global" table but a lot of them.  The
     term "global" becomes a little bit strange.

  2) The global-table is attached to Lua functions.  You are no longer
     able to switch to another "global" table.  You have to explicitely
     change each and every function (hard/impossible to do).

  3) It introduces a hard to track dynamic binding.  It's impossible to
     tell which object is accessed by an identifier.  The binding is
     done dynamically at a later point (even while a function is active).

     [I.e. do you recognize, that the test/readonly.lua example works
     only for the current chunk and new functions defined in it?  Old
     functions and newly loaded ones may still modify globals.]

  4) Lua "globals" and C "globals" become different things.  You cannot
     expect any more that a global in Lua is visible in C and vice versa.
     (Ok, Lua<->Lua is the same as is dostring...)

Then I saw the caching of globals in Roberto's module library - you get
strange effects if you try to replace globals like error()...   I think,
that such a module lib is the only sane use of the "local-globals" but is
it worth the price?  All these global table tricks?  I don't like it.
Too much complexity for too little gain (what gain anyway?  A little bit
less typing?  [1]).

Sorry, to be again the one who rants about a new feature :-/

Ciao, ET.


[1]:
> local mod_init = function()
>    -- a private variable
>    local val
>    -- a public function
>    function foo(x)
>      val = x
>    end
>[...]

IMHO, even

  local val
  mod_table = {}
  function mod_table.foo(x) val=x end
  function mod_table.bar(x) print(val) end

is easier to understand than these global table tricks.  [But I also
think, that the C++ rules to determive which identifier accesses which
object are flawed.  You never know whether it's some class member or a
global or an enum or whatever else...]  Sure, using  self.val  or
mod_table.foo  is a little bit more to write but everyone understands
that immediately (even oneself after a couple of months have gone ;-).