Re: modules, require, magic

[Doug Currie <doug.currie@...>]

On Oct 18, 2011, at 1:53 AM, David Manura wrote:

> On Mon, Oct 17, 2011 at 1:00 PM, Sam Roberts <vieuxtech@gmail.com> wrote:
>> Now we are trying to support two ways, check out this code at about line 60:
>>  https://github.com/dcurrie/lunit/blob/master/lunit.lua
> 
> 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:
>  http://lua-users.org/lists/lua-l/2006-04/msg00547.html
> 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.
>