lua-users home
lua-l archive

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


David Given wrote:
Irayo wrote:
[...]
  
So, what's the best way to implement multiple reloadable scripts and
make sure that they don't have member collisions, and yet have them
still interact with each other on a limited level?
    
A Lua module, once loaded, basically ends up being a dictionary. When you
call, say, io.open(), this is sugar for _G["io"]["open"]. _G is the current
module's global environment (a.k.a. local namespace).

So, if you have modules called Hand, Foot, and Eye, you could quite easily
have syntax like Hand.MoveTo(location), Foot.Forward(distance), and
Eye.Sense(). Each module has its own separate namespace, so you don't get
collisions; but it's also possible for a module to obtain a reference to
another module, so that different modules can communicate with each other.

The end result is that all your modules can have a symbol called Foot that
refer to the *same* object, and they can all have a symbol called fnord that
refer to *different* objects, depending on the usage.

Unloading can be done easily by nilling all entries from a module's
dictionary, as you describe. Reloading is very slightly trickier (because the
module still exists but is empty, so you have to trick Lua's module system
into rerunning the script to repopulate the module), but not much so. It *is*
possible for a module to have private members by using the 'local' keyword ---
local variables don't get stored in the module dictionary but instead exist on
the Lua stack. (Which makes them much faster, too.)

So that's all easily doable.

However, security issues are much harder. Lua basically doesn't do security.
It's possible to very easily set up sandboxes where you can deny access to,
say, loadfile() and require(), but ensuring that you haven't accidentally left
holes in your sandbox that allow privileged escalation is infeasibly hard. So
you can make it *difficult* for your programmers to break things, but it's
very hard to make it *impossible*. Frankly, if your programmers aren't going
to be actively malicious, I'd be inclined not to bother --- if you enforce
decent coding standards and bite people's heads off if they access things they
shouldn't, they should get the message.

  

Wow, alright, thanks :-P

That answers practically everything I needed to know.

--
Irayo