Re: and Lua marches on

[Vaughan McAlley <ockegheim@...>]

2009/12/16 steve donovan <steve.j.donovan@gmail.com>
>
> On Wed, Dec 16, 2009 at 1:11 AM, Tobias Kieslich <tobias@justdreams.de>
> > I entirely agree on Lua missing stuff, generic libraries that make the
> > implementation of common tasks easier.
>
> One way is to clone interfaces from other libraries. Like I've used
> the interface for Python's os.path module for Penlight's pl.path:
>
> http://penlight.luaforge.net/api/modules/pl.path.html
>
> This doesn't mean I think this is the ultimate, or a standard, or
> anything like that. It's just a convenient starting point, given that
> lots of people have used this interface.
>
> The ultimate test is whether all common path operations can be
> expressed as one or two of these functions. Maybe we do need some
> more, but they do need to be basic operations so the module can remain
> compact and easier to remember.
>
> (path.tmpname() is there because trusting os.tmpname() can let you
> down badly on Windows, since it doesn't prepend an appropriate temp
> path)
>
> steve d.

Could a relatively close-knit (and harmonious) community like the Lua
community come up with APIs for what we consider to be "standard"
libraries. For example, if it was expected that an XML parser would
take an XML string and return a nested table, you could have something
like this:


local xml = require("JoesXMLLib") -- or another preferred library with
the same base functions

...
resultTable = xml.parse(inputString)


Existing library authors could alias or wrap their functions to the
"standard" API.


Vaughan

PS Sorry if I'm reinventing the wheel or don't understand libraries
well (I installed my first library last night, called my test file
"socket.lua", and spent a couple of hours wondering about the
mysterious "loop or previous error loading module" error- if anyone is
googling this page, don't give your test file the same name as the
module, or it will try to load itself).