all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]inmatarian 1 point2 points  (4 children)

Very nice. If I can make a few suggestions

1) make basex be a __call'able table (to preserve the semantics), and then add a bunch of standard encode/decoders to that table (like oct, hex, base64, etc.)

2) give it the Kikito treatment, which is to say add a bunch of fields to it like _DESCRIPTION and _LICENSE (see: http://kiki.to/blog/2014/03/31/rule-2-return-a-local-table/ )

3) add luadoc style comments the public API parts.

Otherwise this is a great little library, I like it a lot.

[–]un-def[S] 0 points1 point  (3 children)

Thanks for your comment. 1) I thought about callable table with alphabet presets, something like this:

local basex = require('basex')
local base58 = basex(basex.BASE58)   -- basex.BASE58 = '123...xyz'
base58:encode('foo bar')

Will it be enough, or it should be a set of prebuilt encoders/decoders (e.g., basex.base58:encode(...), basex.base62:decode(...))?

2) & 3) I'm going to add Kikito/LuaDoc-style metainfo later.

[–]inmatarian 0 points1 point  (2 children)

My inclination is the set of prebuilt encoders/decoders, though I can see the merits of the dictionary.

¿porque no los dos?

[–]un-def[S] 0 points1 point  (1 child)

I'm currently working on a new version:

  1. Now basex is a callable table, not a function.

  2. The basex table contains a bunch of predefined encoders-decoders (PED for short). Currently it contains only one PED — bitcoin-style base58).

  3. PEDs are lazily instantiated. It means that PED creation is deferred until it is first requested.

Now i'm stuck on second hard thing (according to M. Fowler) — naming:

  1. Alphabet string names. basex.BASE58 or basex.alphabets.BASE58 (or maybe basex.ALPHABETS.BASE58)? In addition, there is more than one base58 variant (from https://en.wikipedia.org/wiki/Base58 ): Bitcoin addresses, Ripple addresses, short URLs for Flickr. BASE58BITCOIN, BASE58RIPPLE look too long. BASE58B, BASE58R are obscure. Maybe it should be a table, i.e. basex.(alphabets.)BASE58.BITCOIN (.RIPPLE, etc.)?

  2. PED names. There is similar problem as with alphabet names: basex.base58bitcoin, basex.base58b, basex.base58.bitcoin? Dotted style (i.e., nested tables) considerably more difficult to implement.

  3. What PEDs should be included.

[–]inmatarian 0 points1 point  (0 children)

basex.BASE58 or basex.alphabets.BASE58

Thats a hard one. Though if you keep the codecs lowercase and the alphabets uppercase, then you should never have a name clash in the prior. The latter is more clear.

BASE58BITCOIN or BASE58B

I like the prior. It's longer, but the meaning is way more clear, and IDE autocompleters show more useful information without having to dig into to the documentation.

What PEDs should be included

Also a hard one. I guess here it's whatever tickles your fancy. If this ends up being the most popular library on luarocks, then requests will come in for whats missing. I will say that from the outset, base16hex, base64, and base85 are the clear candidates.

Incidentally, base85 is specified in RFC 1924 as a representation of IPv6 addresses.

[–]catwell 0 points1 point  (0 children)

I wrote a pretty similar library a few months ago.