[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Packaging and importing
- From: Mark Hamburg <mhamburg@...>
- Date: Mon, 15 Aug 2005 08:09:39 -0700
on 8/15/05 5:50 AM, Tomas at email@example.com wrote:
>> I don't have a good answer for how to encourage people to use the last form,
>> but it's a simple change to module to get them to use the first form.
> Please, could you elaborate on that? What change on module()
> are you proposing?
Don't have it populate the global namespace. It did last time I looked and
the discussion in this thread suggests that it still does. (If that's
changed, then this is all irrelevant and I apologize for consuming
bandwidth. I don't have w6 handy on my e-mail machine at the moment.)
This change "fixes" two things:
1. It prevents using require and then referring to the required entity via
the global instead of a local.
2. It discourages relying on some other piece of code doing the require that
populated the global namespace.
The downside is that it makes command line coding more of a pain. If table
were a module for example, you would have to write:
require"table".foreach( t, print )
In order to print the contents of t. Rather than:
table.foreach( t, print )
Assigning into locals at the command-line level is of limited value because
the locals don't last past the end of the chunk. (See some of the
discussions about local v global for related issues.)
One way to deal with this would be to have the environment for the command
line do something like the following:
__index = function( t, k )
local v = _G[ k ]
if v ~= nil then return v end
v = require( k )
t[ k ] = v
This automatically tries require when the name isn't found within the
environment and adds the results to the environment, but it is only intended
for use on the sandbox environment for the command line.