RE: Standard Lua Library

[Jay Carlson <nop@...>]

Why not proxy os.* into osx.* ?  You can always do

local os = osx

In all seriousness, consider ripping off Python, especially things named foolib2.  That tends to indicate that hard lessons in design from foolib have been learned.  

-- 
Jay
Sent from a Treo, excuse infelicities

-----Original Message-----
From: "Natanael Copa" <natanael.copa@gmail.com>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: 1/9/07 4:19 PM
Subject: Re: Standard Lua Library

On Mon, 2007-01-08 at 18:06 -0700, Mark Edgar 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 did. Might be good as reference.

> I don't know much about it.

Not me either. But I found some stuff here:
http://apr.apache.org/docs/apr/1.2/globals_func.html

>
> > 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.

At least they have for both windows and posix. Other people (like me)
only talk and don't do anything.

> > 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?  

To avoid having 3 different modules to chose between for simple
operations. It might be you need some funcs from both the standard lib
(that maybe is not included in lposix) and lposix. I use Lua in the
first place to avoid bloat.

> 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.

Yes, and of course should there be a lposix library for those who do
posix only (like me). But I would prefer having the functions that can
be ported in one single standard library. The lposix would remain and
contain POSIX only things like fork, getuid, setuid etc. But having
funcs for parsing, making and removing dirs would be better to keep in
the standard lib.

> 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.

Yes. Exactly. If i want file system function, then i'd like to load the
file system module. If I want process handling, then load the process
module. I know where my funcs come from, I know where to look for
documentation.

Can you give any examples of other programming languages that does
something similar? inject functions into other namespaces?

If thats the Lua-way of doing things, then fine, lets try get the lua
developers blessing (reference in official lua documentaion such as PiL)

Then also please lets write some docs saying that the "lua way" of
doingthings is to inject stuff in existing namespaces. "This is how you
inject your own funcs that you feel missing in office os module and ex:

...
os.myownfunc()
...


> However, I feel that in order for such an API to be useful, it must 
> integrate strongly with the core libraries.  

I strongly disagree. If the core libs are too thin or not good enough,
then fix the core libs. I think that the core libs should be as they
are: thin. Add new name spaces to the optional stuff you might want.

> 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()

I would prefer something like:

require "env"
env.get()
env.set()

require "proc"
proc.sleep()
proc.create()
proc.wait()

require "dir"
dir.getcurrent()
dir.setcurrent()
dir.make()
dir.remove()

for e in dir.iterate() do
   ...
end

lock and unlock could probably go into the Lua core.

> 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

Hackish, IMHO. Better fix the lua core if this really belongs there. If
not, give it a new namespace.

If I'm completely wrong, and this is the "Lua way" of doing things, and
the Lua developers encourage this way of doing things, please let me
know. Then sure, I'm in.

--
Natanael Copa