Re: Is there any plan to include build-in class support?

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

On Thu, Jan 13, 2011 at 11:39 AM, Fabien <fleutot+lua@gmail.com> wrote:
> I miss a stronger culture of code reuse in the Lua community, but I don't
> think *you* can/should do anything about it, at least today.

Well said - that separation of concerns is a strength.

Lua has an interesting culture of micro re-use, based on recipes and
snippets.  There are actually a lot of libraries available, which
scratched some person's itch/need, but are insufficiently documented.
Generally they do something that is impossible or inefficient in pure
Lua.

With Penlight I wanted to provide reusable pure Lua libraries, but
perhaps at the wrong level of granularity because of inter-module
dependencies.  It is irritating to use a 200K library if you just want
to split a string.  For the next iteration I aim to package it as two
Rocks[1], penlight-core and penlight-dev, with penlight-core having
the commonly used code (around 20K) and the other having the
documentation and the more specialized stuff (where to draw this line
is an interesting question).  Also, I aim to reduce the coupling so
that more modules can be simply used directly.  Then I can act more
like a curator or an editor and accept more modules, as long as they
are sufficiently general in purpose.[3]

Lua libraries are classic 'shared library' thinking. Mathew Wild's
Squish suggests another model where you may develop against modules
and later 'statically link' against them;  I would like to support
this in Penlight, precisely because of the 'I just want to split a
string' complaint and that requires special control over dependencies
and some interesting code analysis which I'm looking forward to.

Another way to organize the strategy is illustrated by the Snippets
site: the implicit dependencies of any snippet are discovered through
source analysis. This allows the following workflow: you see a snippet
that does what you like, and hit a 'raw' link: you will then get
_self-contained_ code to do that particular task.[4]  This allows
snippets to build on other snippets without ending up with manual
dependency-chasing.

My apologies for going on about a personal project, but reuse (and the
resistance to reuse) is very much at the heart of it.

steve d.

[1] why not take this further? Many little rocks? Apart from the
administrative overhead[2] , I think this can go too far. But
certainly some of the more specialized code (like the command-line app
mini-framework lapp) can be spawned off and maybe separately
maintained.
[2] not just for myself and collaborators, but also for the Hisham and Fabio.
[3] For instance, code that does (say) XML, networking, GUI, etc
should live elsewhere.
[4] Intended feature, if there's sufficient interest. There's a Delphi
snippets site which works like this. In the LF2 discussions we also
considered the auto-conversion of snippets into Rocks.