[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Is there any plan to include build-in class support?
- From: steve donovan <steve.j.donovan@...>
- Date: Thu, 13 Jan 2011 12:23:11 +0200
On Thu, Jan 13, 2011 at 11:39 AM, Fabien <firstname.lastname@example.org> 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
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, 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.
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. This allows
snippets to build on other snippets without ending up with manual
My apologies for going on about a personal project, but reuse (and the
resistance to reuse) is very much at the heart of it.
 why not take this further? Many little rocks? Apart from the
administrative overhead , 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
 not just for myself and collaborators, but also for the Hisham and Fabio.
 For instance, code that does (say) XML, networking, GUI, etc
should live elsewhere.
 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.