lua-users home
lua-l archive

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

On Sunday 08 January 2006 22:58, Rici Lake wrote:
> Very true. However, there is also another criterion, possibly more
> important: ease of use.
> Specifying optional Lua-like interfaces for common features makes
> everyone's life easier.

I can see where you're coming from, but there's another factor to consider, 
which is that of familiarity. I'm a long-time Unix developer. I *know* what 
setenv(), putenv(), unlink(), stat() etc do. When I use those functions from 
Lua, I'd very much prefer Lua's interface to be as thin as possible so that I 
don't have to learn a whole new API style for functionality that I've been 
using for years.

So, while it may be the Lua Way to produce an OO interface to a file system, 
so that you can do:

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

...which is a nice, clean API, I'd actually *prefer*, at least to start with, 
an interface based on stat() because that's what I know how to use:

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

(Yes, I use the lposix library extensively for pretty much everything I do...)

Also remember that any additional layers of abstraction mean extra code, 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.

If you're going to turn Lua into a *platform*, then yes, abstracting over all 
OS functionality is an extremely important thing to need to do. But if it's 
not intended as a platform, then that's unnecessary and, at least in my 
position, actively undesirable.

+- David Given --McQ-+ "There are two major products that come out of
|    | Berkeley: LSD and Unix. We don't believe this to be
| ( | a coincidence." --- Jeremy S. Anderson
+- --+ 

Attachment: pgpbB2iTeKUs8.pgp
Description: PGP signature