|
On 08/16/2010 08:44 AM, steve donovan wrote:
On Mon, Aug 16, 2010 at 5:13 AM, Nevin Flanagan<Alestane@comcast.net> wrote:Putting control in the hands of the caller, however, seems to make sense. So I would recommend that 5.2 retain the default behavior of exporting a loaded module into the calling environment, but as part of require, not module.If you control all the source, then this could work fine. But a single importing require somewhere would disturb the scheme's purity. Personally, I think it's possible to get overexcited about purity. We are accustomed to the standard libraries being globals, so keeping track of another dozen or so globals is no great challenge for person or machine. [...]
I think Perl is a good example, with over 84000 modules coexisting on CPAN, all of them with global namespaces. I avoid runtime globals, of course, but I rather like having a hierarchy of namespaces rooted globally.
The real problem is that not all
commonly-used modules behave in the canonical form, i.e. that require() does indeed return the module, and that the global module name will be 'package.mod' in the last case.
I apologise if I've missed this discussed elsewhere, but does Lua give us a way to "return" the module when creating a C extension library? Feel free to point me to the thread.
Although just about everyone would agree that general use of run-time globals are an anti-pattern, I don't see "_G.my.funky.widget" in the same light: It's a namespace. The builtin Lua libraries do exactly this.
Moreover, as it stands, with module(...) deprecated, the I find the following a really unintuitive:
require "my.funky.widget" my.funky.widget.frob() --> error attempt to index global "my"...More specifically "my.funky.widget" has the semantics of a file-system path, but _looks_ like a namespace. I suspect that this one will bite newcomers to the language.
Cheers, Rich