Re: local "module" pattern without module [was Re: [ANN] SLAXML - pure Lua, robust-ish, SAX-like streaming XML processor]

[Andrew Starks <andrew.starks@...>]

On Tue, Feb 19, 2013 at 12:02 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Tue, Feb 19, 2013 at 4:38 AM, Gavin Kistner <phrogz@me.com> wrote:

> The pattern that Tomas gives puts everything explicitly into the
> master table. Generally the idea is to keep as much in locals as
> possible - which is BTW the reason I'm not so keen on the _ENV 5.2
> construction.

Steve, you ignorant slut....



:) Sorry. I've been really trying to find an opportunity to quote Dan
Aykroyd....


Anyway, good points on _ENV and all. However, _ENV isn't the required
mechanism in my example, and in fact doesn't solve any of the issues.
(I just went on about it because I use it in the same context and find
it helpful)

As you resolved and identified in later posts, the problem might be
described as the flip-side of extending a module and instead, more
like breaking a single class across files.

If the goal is to make a composable library where one might load
whatever one may want and things may or may not be interdependent,
then your solution models the desired behavior more closely. It also
serves the intended purpose here, as well, and does so while keeping
away from the global environment as well as always returning a table.

I think that making sub-modules that return functions, which accept
"self" (or some other state passing mechanism) and return a table of
methods, accurately models the OP's goal. He has a single-purpose
library and wants to divide the problem amongst multiple files, where
only one file would be addressed by the user. Also, the
module-returns-function approach, like your approach, works equally
well in all of Lua-world and performs equally well.

Bottom line is, a great question has brought about multiple great
ideas for how to accomplish the goal of module management, global
space protection and performance (typical Lua). All of them useful at
one point or another, depending on the goals, desired trade offs and
preferred style of programming.

I know that I had a difficult time finding information like this. It
may be on the wiki, but perhaps the context is worded differently
enough that these approaches might be summed up in a new page?

-Andrew Starks


    Simplicity doesn't rot.





>
> I've found myself doing things like this to split a module over
> several files (useful if there's extra functionality you might want to
> load)
>
> --foo.lua
> local foo = {}
>
> function foo.answer() ... end
> ....
> return foo
>
> --foo.extra.lua
> local foo = require 'foo'
>
> function foo.more() ... end
>
> end
>
> return foo
>
> I keep to the 'no magic' style because it discriminates equally
> against 5.1 and 5.2 ;)
>
> steve d.
>