 |
lua-l archive |
|
|
||
|
On 26 Nov 2013 19:29, "Sean Conner" <sean@conman.org> wrote:
>
> 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.
>
We are going to brutally decide on a best interface and officialize it. Somehow. But its going to happen...
Justin
>
>