Re: Suggestion, Lua Sizes

[steve donovan <steve.j.donovan@...>]

> Second: on the other hand, I think a community edition would have some
> advantages even for my use-case. For example, at the moment there is no
> single standard library for Lua. This means if you want (say) container
> classes, you have to write them yourself or cobble together something out of
> a combination of other projects.

We know that Lua tables are very flexible and powerful, but to
communicate programmer intent it's useful to work with specialized and
commonly-known data structures. That convenience becomes magnified
when there are 'standard' implementations (particularly true of
'classes')  Most of us have toolboxes of convenient functions, and
they get used in any non-trivial project. Like functions to split
strings into tables.  I still do this because I don't want to burden
every one of my public projects with Penlight. Granted, it is very
straightforward to make it a dependency using LuaRocks, but this is
not a universally used platform, particularly for the embedded case.

> (e.g.) a "stack" type, but for those who do, they should probably all be
> using the same one.

Personally, 'local push, pop = table.insert, table.remove' does just fine ;)

> even though I wouldn't use the community edition myself, I'd bundle some of
> the modules.

Penlight is designed to be as modular as possible; most modules depend
on pl.utils but otherwise I try to avoid excessive coupling. The file
path manipulation module pl.path has a LuaFileSystem dependency (but
even that is not cast in stone)  It does not depend on the extended
Python-like string functions in pl.stringx.  Similarly the
command-line parsing framework pl.lapp only needs pl.sip ("text
parsing for dummies");  the configuration-file parser pl.config has no
other dependencies.  I am trying to avoid a situation where including
a single useful module (or even function) might implicitly pull in
thousands of lines of library code.

Otherwise, the idea is to use straightforward, idiomatic Lua
implementations suitable for copy 'n paste reuse. That was the
motivation for the snippets site, to collect useful little recipes
together in a more organized way than the wiki.

An interesting possibility is 'static linking' of Lua programs; tools
like Squish[1] point the way here. So the final code has as little
dead code as possible, and is self-contained (very useful in the
embedded space).  The minimal-coupling/straightforward-implementation
design constraints are necessary preconditions for this to work
optimally.

> Same goes for object models -- would be nice to have some ordained "standard" or "reference" ones.

Oh yes. If only the etc directory had a little Lua module called
class.lua!  We would bitch about it (because naturally it would not be
optimal for all use cases) but it would have established a standard
model of inheritance that people would build on.

steve d.

[1] http://matthewwild.co.uk/projects/squish/home