Re: Apache Portable Runtime

[Rici Lake <lua@...>]

Peter Odding wrote:
> Hi all! (again)
>
> I'm writing a binding to the Apache Portable Runtime[1] for Lua. This is 
> my first real C module for Lua and I've run into some `idiom 
> mismatches', so I want to know what other potential users prefer:
>
> *Bitfields*
> APR uses bitfield extensively. Some of this functionality is too low 
> level for Lua, but other stuff I really want to make available. For 
> example when calling stat[2] some properties (13 total) might be 
> expensive to retrieve, so they must be explicitly requested with a 
> bitfield of property flags.

Are these really too expensive to retrieve, compared with the overhead
of a scripting language? Otherwise, it's probably easier all round to
just retrieve all of them.

> Up till now I've used a string where each 
> character maps to a flag. This is concise but feels obfuscated. The 
> other option is to let the user create a bitfield from Lua numbers, 
> which are `constants' my library makes available. This is clear and 
> readable, but very verbose, and the operators | and + are not really 
> compatible, i.e. adding the same flag twice basically destroys the 
> bitfield... Any other suggestions?

As always, I'd suggest using strings. For example, a call might
look like this:

   apr.stat(filename, "inode", "prot", "size")

which would create a table with the same keys (that's nice and fast
because you already have the strings to use as the keys).

Still, I'd really question the value of such a complex interface.

> *Microseconds*
> The `Time Routines' module[3] uses microseconds as it's basic unit of 
> time. Lua uses the C runtime, which most of the time uses seconds (on 
> Windows and Linux at least AFAIK). Should my binding convert between the 
> two, or let users do [T / 1000000] when they want to use os.date or 
> os.difftime? If my reasoning is correct, the division my library makes 
> should not lose precision when Lua uses floating point numbers... Right? 
> Which would you prefer?

I like seconds.