 |
lua-l archive |
|
|
||
|
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