[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Globals (more ruminations)
- From: Florian Weimer <fw@...>
- Date: Sun, 11 Jul 2010 20:56:56 +0200
* Edgar Toernig:
> But however this is addressed, people will realize that accesses
> to table(record/structure)-fields have *exactly* the same problem
> and will start trying to "fix" that ...
That's why I was wondering about http.socket issue. As long as
modules behave like plain tables, it's possible to create global state
in them. I had the impression that this is what happened in the nmap
case, so I asked about that earlier.
It seems possible to solve this, by making sure that the compiler
knows the intend export list of modules. The downside is that you
need to add some sort of phase distinction, like EVAL-WHEN in Common
Lisp and BEGIN blocks in Perl, or you lose expressiveness in a
significant way (you cannot pragmatically created globals anymore).
It turns out to be quite difficult to describe the semantics of this
language facility (looking at some semi-formal and informal
descriptions of EVAL-WHEN is quite instructive), and I fear that it
would by far the most complex of feature once it's added to Lua.
The assignment part of the problem could be dealt with by using
metatables. But I wonder if a function for sealing tables would be
more helpful. It would set a read-only flag on the table and return a
setter function which bypasses the read-only flag. The read-only flag
would only need checking during table writes, and the check would be
virtually free because it never fails on properly written code. This
separates read and write capability and might be useful for
sandboxing, too.