Re: modules, require, magic

[Mark Hamburg <mark@...>]

Let's run through what module does.

1. It handles constructing module tables including the fields _NAME, _M, and _PACKAGE. This is useful if one cares about these fields, but I note that they don't appear in the pre-defined modules like table and string.

2. It handles constructing submodules. I might question whether it makes sense to have socket.http available when socket is potentially just a stub table, but that's a more complicated matter.

3. It provides early registration for the module. This helps with mutually recursive requires, but it also means that require can return an incomplete module.

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.

5. It mucks with the environment to make it "easy" to export functions. But then to compensate for this, it offers package.seeall which results in a module that reveals a lot of globals in its table which have nothing to do with the module -- i.e., it pollutes the API for the module.

So, my evaluation on these is:

#1 is interesting but probably not all that useful.

#2 is potentially pretty useful if one thinks submodules are a useful construct. If we keep modules out of globals, however, I'm not sure the construction really matters. If I have to say "require 'socket.http'" why then does it matter that having said this I can also say "require 'socket'.http"?

#3 is useful at times but also dangerous. It might be better handled through a package.register function.

#4 is a bad thing.

#5 is a bad thing if you use package.seeall. It's a dubious savings if you don't use package.seeall.

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.

Oh. And on the documentation front, the "module( ... )" idiom obviously fails to document the module name and comments are another good way to write documentation.

Mark