Re: Basic, no fuss, no magic, foolproof module pattern. [Was: require, module, globals and "magic"]

[Lorenzo Donati <lorenzodonatibz@...>]

Mathias:
> I don't think you approach is verbose. Personally, I use the "simply
> return a local table from a 'module'" by myself and have not felt the
> need to do something more sophisticated yet. I even do without your
> "read-only" safety measure, thus my solution is even more basic.
Thanks! So I'm not off-track!


Sean Conner wrote:
>   The problem (as I see it) comes down to poluting the global namespace. 
> module() basically loads some code and returns it in a new global table
> (plus maybe some magic).  I know that when I first started playing around
> with Lua modules it wasn't all that intuitive to me.
I Agree, but to me that is only one part of the story. Maybe my vision 
is too constrained by my experience with statically typed languages 
(mainly Java; some C++), but encapsulation and a clean, minimal 
interface with client code is another point to consider.

>   Just in the past few days I came up with the following bit of code:
> [snip]
Ouch! Thanks. I only skimmed through it. It looks interesting, but 
that's an issue somewhat orthogonal (even if strongly related).

I started this thread just because most of the solutions to the "module" 
problem in the WIKI were (like yours) of this sort: reimplementing 
"require", "module" or both, and that was the problem for me. I _was 
able_, with moderate effort, to understand the code in itself, but what 
worried me was that I didn't really understand all the implications, 
lacking enough experience  with Lua. That was why _I_ felt really 
uncomfortable with those approaches (please remember my Lua newbie POV).
(I really hate using a feature without understanding its limits).

>   It wasn't hard to convert the one "module"ized project I have to use this
> and it removed a bunch of lines of code (module(), local defs, etc).  Any
> "globals" in the individual Lua files included via nmodule() become table
> members, and it's up to the caller to determine the name under which the
> file is located.  
>
>   I don't see why a new method like this can't be accepted, along with the
> older method.  

Well, really I'm not knowledgeable enough to express an informed opinion 
on that, nor on whether your technique is better than the other ones 
proposed in the WIKI.
Please, don't get me wrong: I'm _NOT_ proposing that my approach (or a 
similar one) be the standard. As I briefly mentioned on the originating 
thread, I would welcome a widely accepted (maybe endorsed by the Lua 
team) *cleaner* way to "declare" a module (throwing away, as is planned, 
current "module", etc.).

But, until then, for me the main issue is to understand most of the 
implications of my approach, i.e. writing a module with basic Lua 
syntax, with clean, linear structure and no special support from custom 
external functions (no "safe_require", "safe_module" or similar).
And whether that kind of module could be robust, efficient, well 
encapsulated, generally applicable, with no pitfalls (or with well-known 
ones!), i.e "simple and foolproof", even if a bit verbose (compared with 
other approaches like yours, which rely on an additional framework).

Best Regards,

--- Lorenzo