Re: Should tiny utilities be prepackaged?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Should tiny utilities be prepackaged?
- From: Philipp Janda <siffiejoe@...>
- Date: Tue, 1 Mar 2016 23:37:05 +0100
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