Re: Apache Portable Runtime

[Peter Odding <xolox@...>]

I'm trying not to spam the list with to many messages, so here goes a batch reply :)

Rici Lake wrote:
> You might want to reconsider that. It is certainly a clean interface,
> but it might not be particularly useful in common cases. Off the top of
> my head, I'd say the common cases are: checking one or two permissions,
> and reporting all the permissions in some string representation.
> Now, consider these possibilities:
>
> local stat = apr.stat(filename)
> if stat.perms.world.readable then ... end
> -- or
> if stat.worldperms:match"r" then ... end
>
> Just a thought.

My current interface is apr.stat(...).permissions.user.readable, like your first 
example. Which means my 1000/4000 reasoning was wrong; it's actually 5000 
tables: 1000 result tables, 1000 (container) permission tables and then 1000 
each for user/group/world. Are you suggesting the latter of your examples is 
better (sorry, it's late :P)?

> I don't like functions which sometimes return tables and sometimes not;
> that's error-prone and confusing to the user.

This seems to be relatively common in Lua. Specifically in the reference 
implementation, for example file:read and os.date. But you mention tables 
specifically. Is this because of indexing errors when a scalar is returned 
instead of a table, without the user expecting so?

Mike Pall wrote:
> May I suggest a different API, giving you the best of both worlds:
>
>   -- No property given: return table with all (named) properties.
>   local st = apr.stat(path)
>   print(st.size, st.mtime, ...)
>
>   -- Individual properties given: use multiple return values.
>   local size, mtime = apr.stat(path, "size", "mtime")
>   if size > 0 and mtime ~= prev_mtime then ... end
>
>   if apr.stat(path, "type") == "directory" then ... end

I like it :). I haven't rewritten my code just yet, but I think I'll go with 
your proposal.

> Well, Lua can be compiled with an integer number type, e.g. for
> embedded platforms. Sub-second timing seems relevant for embedded
> platforms (except for the file APIs maybe).
>
> So you might want to return two numbers (seconds, microseconds)
> or a table or a userdata type in this case. But of course this
> will break portability with Lua installations using doubles or
> floats.
>
> I don't see a clean solution. Maybe apply YAGNI and wait until
> someone complains (and let'em explain what they really need).

I was thinking about embedded platforms aswell, but then, how much embedded 
platforms will be supported by APR? Currently none, or so it seems[1]:

 * UNIX variants <- still wondering how inclusive this is
 * Windows (embedded as in CE stuff? does that require integers?)
 * Netware
 * Mac OS X
 * OS/2

Does this make the point moot or not? I seem to remember reading that regarding 
performance double/float/integer(?) doesn't matter much anymore on modern (x86?) 
processors. Is this still a valid reason to compile Lua with integer numbers?

I don't feel much for a userdatum, though this would be technically superior 
since a time-type should be implementation defined, not a regular number. Going 
with a userdatum would solve the os.date/os.difftime issue aswell since those 
functions won't accept userdata anyway.

I could of course just use a preprocessor macro which can be defined to push 
seconds (default) or microseconds. One the one hand, this offers the same 
flexibility as Lua, on the other hand this creates two incompatible libraries 
which doesn't smell right. Then again, 30% of all lua sources/bytecode is 
incompatible with integer numbers aswell by assuming floating point support... 
Argh: The choices! 8)

Jérôme Vuarand wrote:
> The problem already is also present with doubles. I made the
> following quick test, and it appears that about half numbers
> between one and one million get rounding errors with the
> conversion we are talking about (an integer in microseconds
> to a float in seconds).

This would suggest that a userdatum might be a better solution? (asking all..) 
Which would BTW enable a __tostring metamethod with a default date representation.

Thanks for your input people! (also the ones I didn't quote -- all opinions welcome)

 - Peter

[1] http://www.apache.org/dist/apr/Announcement1.2.html