 |
lua-l archive |
|
|
||
|
On Aug 7, 2010, at 5:10 AM, Mark Hamburg wrote:-- Define a module with functions foo and baz: local M = { } return MThis hardly seems particularly bizarre and it doesn't rely on tricks with environment to change global assignments into exported values.
On 7.8.2010, at 15.33, Petite Abeille <petite_abeille@mac.com> wrote:
Two things:(1) The above setup implicitly assumes a one-to-one relationship between physical Lua files and module names. In other words, the name of the module is derived from the physical file name the code resides in.
I don't understand how the proposed system is different in this aspect from what we have now. The only implicit reference to a file is the param to require and all other references originate from that (e.g. package.loaded). That's not going to change, is it?
Users could still rename the module as they like (local xyz = require...). I guess i'm not getting something...
(2) The namespace accessible to the module is global, as opposed to a more self-containded, closed environment provided my the current module/setfenv (i.e. package.seeall vs. not).
Why is it important to restrict access to globals inside modules? Why the rules concerning globals should be any different inside and outside a module?
With the new convention modules wouldn't be creating new globals by recommendation so basically creating a new env for modules would just hide standard libs and standard functions like print, require etc.
If you're worried about modules accidentally creating new globals then with envs we would be just trading one bug to another: creating new module scope variables by accident.
Petri