Re: modules, require, magic

[Sam Roberts <vieuxtech@...>]

On Mon, Oct 17, 2011 at 9:07 AM, Petite Abeille
<petite.abeille@gmail.com> wrote:
>
> On Oct 17, 2011, at 4:28 PM, Javier Guerra Giraldez wrote:
>
>> module() is gone,
>
> It's not gone. It's alive and kicking in 5.1.
>
> 5.2 is not released. In 5.2, it might  be deprecated. Which means it's going to be there for years to come.
>
>> the replacement is far simpler,
>
> Bollox :)
>
>> I really don't get why to keep discussing about it.

Because module and require worked fine, and provided a common way to
implement modules.

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

> Well, is there a party line we have to toe? Or is it acceptable to voice discontent?

Petite, probably its not useful to voice discontent... though I share
your pain, and I'm going to voice mine, too!

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.

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.

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 (you can't have two modules named "bit", not
with the old module(), and not with the new _ENV={}, return _ENV
idiom, either).

Given that the names cannot collide, injecting them as globals is handy.

However, this is clearly the losing side of the argument, and I won't
be porting our codebase to 5.2 for quite a while, anyway.

Having two ways to define modules is going to make it harder to keep
my published modules up to date and useable for both lua versions. Lua
is not exactly swimming in an ecosystem of useful libraries, having
most of the 5.1 ones not work in 5.2 until they are ported to the _ENV
system is a bit awkward, but so it goes.

Cheers,
Sam