Re: modules, require, magic

[Sean Conner <sean@...>]

It was thus said that the Great Mark Hamburg once stated:
> Let's run through what module does.
> 
> 4. It adds the module to the global namespace. This, in my opinion, is a
> bad thing because it creates hidden dependencies -- i.e., code can use a
> module that it never required simply because some other code required it
> earlier and it became available in the global namespace.
> 
> So, my evaluation on these is:
> 
> #4 is a bad thing.
> 
> Obviously others differ, but I think it would be useful to hear which of
> these behaviors is deemed so valuable that people are fighting for it.

  I'm still thinking on the other items, but for this one, I'm not sure if I
like module() adding to the global name space or not.  I can see why it one
would like it *not* to add to the global namespace, but on the other hand, I
can see a reason *for* adding a module to the global namespace.

  For the modules I've written, since they do fall into the global
namespace, is that I carved out a global namespace for myself.  All my
modules I've written are placed under the "org.conman" table (taking an idea
from the Java world) in order to prevent clashes.  So code that's expecting
DarkGod's DNS Lua module won't blow up with my DNS Lua module.  

  But a reason for a global module is as follows:  I have a Unix module
(org.conman.unix) that stores a few tables that list the users, groups and
programs on a Unix system.  For example:

[spc]lucy:~>lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> show = require("org.conman.table").show
> unix = require("org.conman.unix")
> show(unix)
paths         table: 0x874ae20                                             
_PACKAGE      "org.conman."                                                
_DESCRIPTION  "The list of users, groups and programs on this Unix system" 
_NAME         "org.conman.unix"                                            
_COPYRIGHT    "Copyright 2010 by Sean Conner.  All Rights Reserved."       
groups        table: 0x8755ce0                                             
_M            table: 0x873d678                                             
users         table: 0x873d7a8                                             
_VERSION      "1.0"                                                        
> show(unix.users['spc'])
uid     500           
name    "Sean Conner" 
gid     500           
userid  "spc"         
home    "/home/spc"   
shell   "/bin/bash"   
> print(unix.paths['firefox'])
/home/spc/bin/firefox
> 

  Assume for a moment there are several other modules that require this
module.  Without a global namespace, each module will get their own copy of
this module, which would mean wasted space as there are multiple copies of
this data (and that paths table could be pretty big ... [1])

  "But module() and require() could keep a private table with references to
each module and not dump them into the global space," you say.  Okay, but
you *still* need a global namespace, because DarkGod has *his* DNS module
(named dns) and I have *my* DNS module (which would also be named "dns"), so
which one is returned when you require("dns")?  (assuming that I have
modules I wrote using my DNS module, and some other modules I want to use
might be using DarkGod's DNS module)

  Perhaps a question is in order:  has anyone experienced a module name
clash?

  -spc (I have, quite often.  Often enough that I'm using org.conman for
	my namespace ... )

[1]	It's empty initially, until you try to index it; at that point it
	will look through $PATH for the executable, save the results to that
	table, and return it.  Next time it's indexed for the same name,
	it'll return the cached result.