Re: os.setenv()???

[Rici Lake <lua@...>]

On 8-Jan-06, at 6:27 PM, David Given wrote:

> Also remember that any additional layers of abstraction mean extra 
> code,

As I said before, changing the name of a function (from putenv to 
setenv, or from Write to write) costs nothing. :)

>  and
> Lua is primarily an *embedded* language. Most Lua programs aren't 
> intended to
> be portable because the author knows exactly the platform that it's 
> going to
> run on.

I wonder if that's true. I've primarily used Lua for two things:

1) A configuration system for utilities
2) A glue language for scripting internet servers.

In both cases, the embedding application is attempting to be 
cross-platform, often at an agonizing cost. The configuration / 
scripting interface, which is designed for non-programmers, attempts to 
abstract the differences away (fortunately, that's not usually 
difficult.) Such people would probably not like either:

filesize = 
RootFilesystem:findfile("/home/dg/documents/sample.txt"):size()

or

filesize = posix.stat("/home/dg/documents/sample.txt").st_size

but the first would at least work consistently on Unix, MacOSX and 
Windows, which saves me a lot of documentation effort and makes it 
easier for the clients to switch platforms without rewriting their 
scripts. (I'm skating over the backslash issue here, although 
fortunately slashes work on windows these days; the biggest problem is 
convincing people to not write backslashes or to double them. These are 
the sort of things that create helpdesk calls. I'd hate to think of the 
complications which using .st_size might cause :)

I find that it's pretty easy to get people to write stuff like:

for f in folder(env.HOME) do -- [Note 1]
  if f.extension == "doc" and f.size > 4 * megabyte then
    print(f.fullname .. " is way too big.")
  end
end

In fact, I prefer that myself :)

I don't see how that creates extra code. Supporting N platforms with 
different directory APIs creates extra code, but thin wrappers don't 
help that; on the other hand, using thin wrappers bulks up every 
script, whereas the support code is only written once.

Let me be 100% clear. I am not proposing any of the following:

-- bundling a large set of cross-platform libraries with the standard 
Lua distribution

-- shooting people who write platform-specific interfaces

All I'm suggesting is that if we put our heads together, we ought to be 
able to come up with a nice clean set of documented interfaces which 
*could* be used by people to implement OS support libraries in a 
standard, Lua-like way. The market would then decide, I suppose, but 
I'd be betting that the standard interfaces would have a lot of market 
support.


[Note 1]
To handle the difference between Windows and Unix environment 
variables, I use a pseudo-environment table which translates names. I 
wouldn't suggest doing that in a standard interface, but it's avoided a 
lot of problems.