[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua Ecosystem
- From: Sean Conner <sean@...>
- Date: Tue, 26 Nov 2013 14:28:35 -0500
It was thus said that the Great Michal Kolodziejczyk once stated:
> On 26.11.2013 09:21, Sean Conner wrote:
>
> > And we get back to my problem---I have a Lua UUID module [1] (right now
> > called 'org.conman.uuid') that supports more UUID types than just type 4 (it
> > supports types 1, 3, 4, and 5---check out RFC-4122 for details). I'd like
> > to make it available. What are my options? I can't call it 'uuid' because
> > that's taken (at least twice).
>
> Hello,
> here is my proposal - hopefully solving most of your issues, and
> creating another ones ;)
>
> I think that the "official API" should be decoupled from "conrete
> implementations", so the user could choose between "community preferred"
> module or his own preference.
>
> I have just commited the description and sample code to github here:
>
> https://github.com/miko/LuaEco
I took a look, and there's still an issue. Take syslog for example (as
this is something I have looked into a bit more than the UUID libraries).
All the syslog modules do support a "log()" function. So far, so good.
But, one module uses:
syslog.log(syslog.LOG_ERR,string.format("warning: x=%d",d))
another one:
syslog.log('LOG_ERR',string.format("warning: x=%d",d))
And a third one:
syslog.log('err',string.format("warning: x=%d",d))
And a forth one:
syslog.log('error',"warning: x=%d",d)
Three take two parameters; one takes multiple parameters. Three take a
string as the first parameter; one takes a number. Of the three that take a
string as the first parameter, one only accepts a string version of the C
constant; one takes a shorthand notation and the third accepts a longer
version of the shorthand notation. The one that takes multiple paramters
works a lot like string.format().
None of them are completely, 100%, compatible.
So, which one is the "official API?" There are two that are closer to the
C API; one that is just plain easier to use (the last one); one that is in
the middle.
I'm not trying to shoot your idea down, but there are issues I think you
missed.
-spc