Re: Lua library bank?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Lua library bank?
- From: Dirk Laurie <dirk.laurie@...>
- Date: 2013年3月10日 07:18:08 +0200
2013年3月9日 David Heiko Kolf <kolf@gmx.de>:
>
> In my opinion even the libraries in LuaRocks are not all high quality.
> And to me that is one of the problems in the Lua universe. The Lua
> interpreter is really high quality, but I am often not satisfied by many
> of the libraries.
>
> So I would prefer a standard library where all the code follows some
> coding style document, that gives general advice on how to write a good
> C module or a good Lua module.
>
…
>
> - Even more subjective and hard to define, but a module should show some
> "Lua-style". Sometimes I see a module and it looks to me like raw C
> bindings and I keep thinking that the API might be a lot simpler in Lua.
>
…
David, this is the most useful post in this thread so far. It gives
criteria to which software in the library bank should conform.
Let's turn it into a constructive proposal.
1. Once the debate on your guidelines (there is bound to be some
disagreement — this is lua-l!) has settled down, we start a page
LibraryBank (or whatever) linked to LuaAddons on LuaWiki saying:
these are the guidelines, and here is a list of modules claimed to
conform to them, each complete with a short description and a link
that takes you to the repository where it can be found.
2. The normal dynamics of a Wiki maintains that page: anyone may add a
new item: the developer, an enthusastic user, anyone. Since LuaWiki
does not have Talk pages, negative experiences should just be added
by the dissatisfied user (keep it short: "last updated February
2009", "fails to build on Solaris" etc.).
3. Software developers can consult that page before releasing their
software to decide whether to aim for those standards. We must not
be too strict: we should not exclude software which, for a good and
unavoidable reason, fails to follow some particular guideline. For
example: we may decide that all modules written in C should conform
to the same standard of general portability as the Lua source code,
but someone may write software for which C99 is essential. Such a
transgression should not be grounds for exclusion, as long as it
is clearly stated and well motivated.
4. We could design our own .css style for documentation, different
enough from PUC-Rio's style to make confusion unlikely, but used for
all software that makes the LibraryBank grade. Authors could provide
documentation in Markdown to make the HTML conversion automatic.