lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Oct 17, 2011 at 1:00 PM, Sam Roberts <> wrote:
> Now we are trying to support two ways, check out this code at about line 60:

That's ugly, though not necessary either.  I would, like Luiz, avoid
using both _ENV and 'module' for module definition.

> The occaisonal suggestion that lua programmers widely disliked
> module() is pretty galling, and I'm tempted to deface that wiki page
> people keep pointing to like it represents some kind of consensus
> opinion, when its only the opinion of a few.

The page (which is my fault ;) ) could use a little updating/more
balance indeed, starting, I believe, with Hisham's comments.

> I like module(), in particular, I like the behaviour that it sets up
> globally reachable names for modules, and I like that I can call it
> like module(...,package.seeall), and while containing no internal
> reference to its actual name, it will build itself into the global
> namespace depending on where its deployed in the filesystem.

I understand other pro-module users would not agree on those points.
Petite Abeille and Hisham said (or suggested) it's ok to get rid of
luaL_pushmodule, and Hisham argued the benefits of explicitly writing
out the name to module.

Personally, I've thought that if you do want to design the module
system to automatically set up global names, this responsibility
belongs more inside a function loading the module (like require) than
a function defining the module (like the module function).

> The require() function defines a namespace, a namespace that is global
> to the lua state, inherited from the filesystem, and in which
> conflicts must be avoided

Mark Hamburg had argued that the main problem is not conflicts but
rather hidden dependencies:
Improving visibility, I believe, follows in the same vein as some of
Hisham's recent comments concerning passing an explicit module name
and other things.