lua-users home
lua-l archive

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

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

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


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

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.