update utils; enum + kpairs

[Tieske]

adds:

• feature: utils.enum accept hash tables as well
• feature: utils.kpairs iterator over all non-integer keys (inverse of ipairs)

[kalekje]

...should we add kpairs to tablex then?

[alerque]

...should we add kpairs to tablex then?

Putting it in utils next to the existing utils.npairs does seem like the most consistent thing. That being said I would probably me most likely to look for it in tablex.

[Tieske]

we could move all of them; pack, unpack, npairs and kpairs to the tablex module. The main problem we'd have with that is probably the dependency tree (inter dependencies between PL modules).

I think @stevedonovan made an effort to decouple them, such that most would rely only on utils and compat. If we move them then we'd undo that since pack and unpack are used all over the place iirc.

[kalekje]

Thinking about it some more, it does make sense it's in utils. I'd probably just use kpairs = untils.kpairs and with unpack anyway.

[Tieske]

we can also add them to utils, but include an alias in tablex. Such that they are where users expect them, without adding extra dependencies.

[alerque]

I don't think we need an alias, but a nod in the tablex documentation to the additional table related utilities in utils in case one comes searching for them might be useful.

[Tieske]

@alerque any specific reason you don't like an alias? There's already plenty of them, see the file module for example.

(an Alias might also make the docs easier, since we can attach Ldoc comments to an alias)

[alerque]

If there is already precedent to get docs then okay, just go for it.

My personal dislike of multiple aliases for the same code path is rooted in history with other projects where the difficulty of refactoring things later goes up the more ways there are of accessing the same code. For example in this case when looking for uses in a code base you can't just grep the Lua code for utils.kpairs, you'll have to grep for (utils|tablex).kpairs. In this case "kpairs" is likely to be unique anyway, but the same is not true for most API calls.

[kalekje]

To be fair, we don't call pairs or ipairs like table.pairs() or x:pairs() anyways, so it's not really clear to me why kpairs should be an exception.

[Tieske]

merging this for now, at some point (before 2.0) we probably need to revisit some of the function in utils anyway, and the module separation (interdependencies)