lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, Oct 18, 2011 at 6:47 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Josh Simmons once stated:
>> On Tue, Oct 18, 2011 at 6:20 PM, Sean Conner <sean@conman.org> wrote:
>> >
>> >  "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)
>> >
>>
>> Require already does this, and you need to separate them at the
>> filesystem level irregardless of what scope they're imported into.
>>
>> local dns = require 'crazy.weird.dns'
>> local dns2 = require 'somebody.elses.dns'
>>
>> None of this has anything to do with global scope or module.
>
>  My Lua paths have several locations where modules can lurk:
>
> package.path:
>
>        /home/spc/.luarocks/share/lua/5.1/?.lua
>        ./?.lua
>        /usr/local/share/lua/5.1/?.lua
>        /usr/local/lib/lua/5.1/?.lua
>        /home/spc/work/ecid/tests/common/lua/?.lua
>
> package.cpath:
>
>        /home/spc/.luarocks/lib/lua/5.1/?.so
>        ./?.so
>        /usr/local/lib/lua/5.1/?.so
>        /home/spc/work/ecid/tests/common/lib/?.so
>
> (that last path in each is for work related Lua stuff)
>
>  And just doing a
>
>        require "dns"
>
> will grab the first file matching dns.lua or dns.so, and woe to code that
> expects CrazyWeird DNS module (living under /usr/local/lib/lua/5.1/dns.so)
> and gets SomebyElse's DNS module (living under
> /home/spc/.luarocks/lib/lua/5.1/dns.so).
>
>  -spc (So yeah, the filesystem does this to a degree, but you can still
>        get messed up ... )
>
>
>
>

What I'm getting at is this is tangential to module issues, if your
paths are crappy you're in trouble no matter how you name your module
and if your paths are good it doesn't matter whether you use module or
not.