lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Am 01.03.2016 um 19:21 schröbte Sean Conner:

[...]

   Because that way lies madness.  For instance, table.copy().  Is it a
shallow copy?  A deep copy?  How are cycles handled?  If the same table
appears twice (but not in a cycle), is each one copied?  Or one copied and
the other a reference?  There's no one solution.

I once saw a talk by a C++ guy about <algorithm>s. He said that you'd want a whole collection of variants of basic algorithms (he specifically mentioned `copy_if`), because those are the algorithms that you will most likely need. I think I agree with him, and so I would actually like to see a specialized `table.copy` module that includes the most common ways you'd want a table copied plus maybe a modular way to get a copy function tailored to your specific needs (Please, module, give me a function that does a copy two levels deep, handles metatables, and calls a `__copy` metamethod when it encounters a userdata, but I don't expect any cyclic references!).


3. Should we make any attempt to standardize the name and
functionality of such routines, in the hope that one day a Lua
standard library, widely accepted by the community, will emerge?

Mu.

I think it's already happening. This is list of modules I consider Lua's extended standard library (in the order they are mentioned on the Lua Toolbox):

*   luafilesystem
*   luasocket
*   lpeg
*   luaexpat
*   semver
*   vararg
*   luasql
*   lrexlib

All listed modules are portable (some as portable as Lua, but most of them run at least on the three major desktop OSes and the last three Lua versions). They are comprehensive and useful to more people than just the original author. They have a clear focus. They are as general as possible (lxp.lom is an exception). They have won against competing modules (not sure about luasql vs. luadbi, though). And they are more or less maintained.

But I think Dirk was talking about utility libraries. In that case I think we will probably never get a universally accepted standard, because what is useful depends on your taste and style of programming. I believe knowing a function name and the module it is in, what it does, what parameters it takes, and what values it returns (or looking all those things up) is more trouble than writing five lines of Lua code. So the existing utility libraries for the most part are too specialized and bloated for my taste.

What I would find interesting is a more scientific approach of choosing functions for a utility library: Scan publicly available Lua code from different authors, collect domain-independent functions that are used more than once, and take the top 30 (or so). Personally, I'd then try to merge as many functions as possible to reduce the number even further, even if that means that I'd have to write one or two more lines of Lua code to achieve the original effect (as I said, I like a small number of versatile functions rather than a large number of specialized ones).


3a. Should libraries like stdlib, Penlight and org.conman make
any effort to become compatible in terms of naming and
functionality?

That would mean that I'll never find a utility library that I will like. And if they are basically the same, we can get rid of one or the other. I think that as long as there isn't a clear winner, neither should be considered part of a standard. However, if the authors of Penlight and stdlib were able to merge the important features (and I don't mean individual functions here) of both libraries into one without adding too much bloat, *that* would be interesting.


Philipp