Re: In praise of globals
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: In praise of globals
- From: Philipp Janda <siffiejoe@...>
- Date: 2013年4月15日 13:55:41 +0200
Am 15.04.2013 12:09 schröbte steve donovan:
On Mon, Apr 15, 2013 at 11:51 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
- no one can mess with your functions once you have them copied (whether
you consider this a good thing depends on how you think about monkey
patching)
This particular point does depend on the order of require() calls, of
course.
Of course. If the environment is already messed up before you are
require'd, you can't do anything about it[*], but typically modules are
loaded before the heavy lifting starts ...
[*]: I suspect unit-testing all Lua library functions at module load
time goes a bit far ...
As for assert(setmetatable), it's less painful to make this a
'compile-time' problem with an appropriate static analysis tool. And I
suspect that the 'luac' trick could be covered as well.
The static analysis tool can't handle all possible situations where
someone might want to use a module. Silly example: Consider writing a
plugin for "Runes of Magic" an MMORPG that can be scripted in Lua 5.1.
If I want to use a third-party module for that I can dofile it (require
is not available in RoM), and if the red icon flashes (assuming the
module asserts on all used Lua functions), this module is not compatible
with the game, and I can start looking for another one before writing
any code myself. From time to time the set of available functions
changes, when the developers have found another way how to write bots.
It's better to find that out when loading the game and not when you are
in the middle of a group of monsters.
I suspect there are lots of restricted Lua environments, where debug is
not available, or the io/os modules are missing (setfenv/getfenv are
likely candidates as well). One might configure a static analysis tool
for the most common cases, but covering all of them is difficult.
Also setfenv/_ENV might complicate the matter for a static tool.
Automating those checks might be possible in some circumstances. E.g., I
have written a Lua-based build tool (like so many before me ;-) ), which
uses lhf's lbci to check that for each GETGLOBAL there is a
corresponding executable in PATH before actually running the build
script. I still use an assert-like mechanism for other dependencies like
include files, libraries, etc., but so far it works like a charm -- I
can even throw multiple build scripts for different build environments
at it and it will figure out which one to execute (or at least tell me
what is missing and where it is expected).
Philipp