lua-users home
lua-l archive

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



You could use a trick that I uncovered lately, to allow for variants of the "ex" loading procedure:

local ex= require "ex" -- load to user's own table (not os, io)

require "ex" (_G)          -- into global namespace

require "ex" "tie-in"      -- into os.*, io.*

require "ex" { "os.pipe" } -- if you want to be really picky

The trick is, having a __call() metamethod in the table that your module returns. Then having that function do the loading in a customized way. I prefer this method hugely over providing a specific initialization function that needs to be separately called.

-asko


On Mon, 08 Jan 2007 18:06:51 -0700
 Mark Edgar <medgar@student.gc.maricopa.edu> wrote:
Natanael Copa wrote:
I agree. I would also like to help if it was possible.

Here are some things I have been thinking:

1. Make a comparison table of all funcions in ex, luafilesystem, lposix
and maybe even their equivalent in apr as reference.

http://lua-users.org/wiki/ExtendedApi

Please feel free to add APR into the comparison mix. I don't know much about it.

2. Make the API. Decide what functions should be included and what the
names should be

The "ex" API was and is intended to be a proposal for an such an API. It provides "standard" O/S facilities beyond what standard C (and thus Lua core) provides.

3. Create the lib.

"ex" already has two implementations one each for POSIX and Windows. They are not terribly clean, have no included build process, and could stand a review.

4. remove all the funcs implemented in this lib from lposix and keep
lposix as a posix specific thing for non-windows stuff.

Why remove functionality from lposix? It stands by itself as a perfectly good POSIX binding for Lua. If your program is not intended for Windows and will never target it, instead targeting POSIX directly, it makes perfect sense to use lposix.


It seems that the biggest strike against the "ex" API is the fact that it integrates into the Lua io and os namespaces. It seems many people feel that this may cause too much confusion for new Lua users.

However, I feel that in order for such an API to be useful, it must integrate strongly with the core libraries. The "ex" API currently integrates with the core libraries in the following ways:

Augmenting the io namespace (io.pipe)
Augmenting the os namespace (many functions)
Augmenting the file metatable with lock() and unlock() methods
Reimplementing os.getenv()
Redefining os.remove() to remove directories
Returning actual file objects from io.pipe()

The proper way to write a portable, stand-alone Lua program with the "ex" API is to always require "ex" in your program, documenting the fact that it will use extensions to the Lua core. Alternatively, one can document the use of extension APIs individually:

assert(os.sleep, "This program requires os.sleep")

					-Mark