Re: Standard Lua Library

[Mark Edgar <medgar@...>]

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