RE: modules

["Philippe Lhoste" <PhiLho@...>]

Edgar wrote:
> If Lua is simply used as a scripting extension of a larger project all
> this is normally not required.  The project defines the environment.
> But if you want to use it as a standalone extendable language some
> policies are required.  And then part of the design is the question:
> "we enforce this policy" or "it only works with self-discipline".
> (I would always choose the later ;-)

There is a third way.
If you don't mind my paraphrasing, I will summarise in other words my view
on the subject:

- Lua can be used as an embedded scripting engine of an application, ie. its
code is integral part of the project.
That's the main aim of this language. It is often the option of games, where
the scripts are probably integral part of the application too, ie. the final
user don't have to know Lua is used here.
Of course, in this case of closed environment, libraries are easy to
integrate, and scripts know which libraries are available and will not try
to access other ones.

- Lua can be also used as a standalone language, like Perl, Python or Tcl.
In this case, you can get scripts that need a given set of libraries (eg.
sockets, regular expressions, etc.). Of course, you can get a copy of Lua
executable with the script. But that means you can end with a number of
various Lua exe. residing in various spaces of your hard disk(s). A waste of
space (although not much, Lua is compact), and a source of confusion. Plus
it kind of ruin the interest of having an interpreted language...

- The third way is to use Lua as a scripting engine of an application, but
keeping the Lua code outside the application, probably in a shared library
or DLL.
It is useful where the users can write their own scripts, like in a text
editor.
The main advantage of this scheme is that end users can upgrade their copy
of Lua (if the new one is compatible, of course) without waiting for the
good will of the creator of their program. So they can benefit of increased
speed, bug corrections, improved features, etc.
And if a system of library modules is available, they can even write scripts
doing stuff that the program creator didn't even imagined (like accessing
CVS, etc.).

So, yes we need a good way to add third party libraries to an existing Lua
executable without having to recompile it. The Perl example is quite good
here, as we have a lot of modules which you can grab as you need.

Regards.

--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--