Re: [ANN] org.conman.iconv (was Re: Modules for iconv)

[Sean Conner <sean@...>]

It was thus said that the Great Dirk Laurie once stated:
> 2014-04-22 7:05 GMT+02:00 Dirk Laurie <dirk.laurie@gmail.com>:
> >
> > Is it still 5.1 only? That would explain it, since my default Lua is 5.2.

  Yes.  I suppose I'll have to add support for Lua 5.2 now that the module
is out there.  [1]

> There are at present two iconv rocks:
> 
> lua-iconv
> 
> Pro:
> 1. It builds under >= 5.1.
> 2. It has names in the module for the error returns, so that one can test
> against iconv.ERROR_INCOMPLETE etc.
> Con:
> 1. The arguments to iconv.new go TO,FROM whereas one's system
> iconv goes FROM,TO.

  I can understand this ordering, as it mimics assignment.  Heck, even I
just recently thought my own iconv() went TO,FROM (I forgot I kept the
system order).

  I'm tempted to adopt this, as that's how I tend to order arguments (dest,
src).  In some other (unreleased as rocks, but available [2]) modules I've
broken from the C ordering of parameters [3] where I felt it made sense.

> 2. It has one metatable only. So you need to say iconv.new to make
> the converter and trans:iconv to invoke it.

  Actually, mine does this as well, only it's open(), not new().

> org.conman.iconv
> 
> Pro:
> 1 .The user interface allows intuitive syntax by returning a callable
> table that returns a callable userdata. So you say iconv(FROM.TO)
> to make the converter and trans(STRING) to invoke it.

  Actually, that was your submission; I haven't added it yet, but I think I
will.  I can see it being more intuitive than calling
org.conman.iconv.open() (or iconv.new() for the other iconv module).

> Con:
> 1. It does not builds under Lua > 5.1.
> 2. It returns the same errors as the system iconv, but you need
> another module by the same author, not available as a rock,
> to make sense of them.

  Okay, another rock to make.  Shouldn't be too terribly hard.

  But the reason I did that is that all my modules tend to return errno (if
applicable) instead of strings.  They're easier to test against, and by
wrapping up all the errno values into a module, easier to manage.

> So I have in the meantime made the version I prefer, which does
> basically the same as org.conman.iconv, but builds under Lua 5.1,
> 5.2 and 5.3, and eturns the converter factory as a function, not
> a table, and gives string error messages, not numbers.
> 
> I'm not saying my version is better than either of the others,
> and it is certainly not original, being a small modification of
> org.conman.iconv, only that I like it better.

  Understandable.

> What my version does illustrate is a fundamental reason why Lua
> will not soon, and maybe never, have "blessed" application libraries.
> Every Lua user has different preferences, and Lua is easy enough
> to modify, even at the C API level, to allow one to implement them
> rather than live with some one else's preferences.

  True enough.  I didn't care for luasocket, so I basically wrote my own
version, in addition to my own version of luaposix (or is it lposix?) and
syslog.

  -spc 

[1]	Personally, I'm still using Lua 5.1, as that's what we're using at
	work.  

[2]	https://github.com/spc476/lua-conmanorg

[3]	For instance, in org.conman.net.socket(), I broke from the C
	parameters:

		int socket(int domain,int type,int protocl);

	for a more (to me) natural form of paramters:

		rc = net.socket('ip','tcp','smtp')

	or

		rc = net.socket('ipv6','udp','dns')

	or even

		rc = net.socket('ip','ospf')

	There's also support for Unix domain sockets as well.